Community
Participate
Working Groups
GET requests should be safe and idempotent. This isn't true for long running Git Log ops. As the result of bug 358079 the response can either be 200, if you're lucky or 202, if the server needs more time to process your request. In case of the latter a task is created, which should not happen for GET requests. A solution, that came first to my mind, is to return immediately for GETs, but for long running ops inform the client that he needs to send a subsequent POST request to start a task (the URL could be in the response). This is an extra round-trip, but I guess this is the price for being RESTful..
Gosia, I think this is another subitem for your progress service work.
I don't think that creating the task is a problem as long as it's not persisted on the server. This is normal that when handling every GET we start some operations and they exist on the server until they are not finished. Than their outcome is send to the server. If we got a timeout the operations wouldn't be probably canceled and we could say they still exist on the server until they finish. I think our problem is that we persist those operations. This is not REST-y. I think this is some kind connected to Bug 366062. The problematic tasks the here are I think mostly GETs. We also don't need them to be persisted.
.
