Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport

> Rogan Dawes <lists@dawes.za.net> wrote:
>> Shawn O. Pearce wrote:
>>> Currently git-http-backend requests no caching for info/refs [...]
>> Fair enough, but what about the quote from RFC2616 that I posted in  
>> rebuttal to Dscho?
>>
>>> 13.10 Invalidation After Updates or Deletions
>>>
>>> ...
>>>
>>> Some HTTP methods MUST cause a cache to invalidate an entity. This is
>>> either the entity referred to by the Request-URI, or by the Location
>>> or Content-Location headers (if present). These methods are:
>>>
>>>       - PUT
>>>       - DELETE
>>>       - POST
>> This doesn't seem negotiable to me.
> 
> Its not negotiable.  POST requires no caching.  End of discussion.

>> For those resources that are expected to be cacheable, the request  
>> should be made using a GET.
> 
> That's exactly what we are doing.  Where caching is reasonable we are
> using a GET request.  Where caching cannot be performed as the server
> state is changing (e.g. actually updating refs) we are using POST.
> That is entirely within the guidelines of the RFC.
> 
> However we are "abusing" POST for "POST /info/refs" to detect a
> Git-aware HTTP server.  Sending POST to a static resource should
> always fail.

>>> Because git-http-backend emulates a dumb server there is a command
>>> dispatch table based upon the URL submitted.  Thus we already have
>>> the command dispatch behavior implemented in the URL and doing it
>>> in the POST body would only complicate the code further.
>> Not by a huge amount, surely?
>>
>> if (method == "GET") command = ...
>> else if (method == "POST") command = ...
>> dispatch(command);
> 
> Well, true, we could do that.  But then we have to break the
> command name out of the input stream.  In some cases we may just be
> exec'ing another Git process and letting it handle the input stream.
> Shoving the command name into the start of it just makes it that
> much harder to parse out.

> One of the problems with these RPC-in-HTTP systems is always the
> fact that the true nature of the action isn't visible in the method
> and URL, causing servers and proxies to have to parse the stream to
> implement firewall rules.  Or to provide access control.  I'm trying
> to reuse as much of the access control support as possible from the
> HTTP server and put as little of it as possible into the backend CGI.
> 
> Since the backend CGI is based upon git-receive-pack itself admins
> can use the standard pre-receive/update hook pair to manage branch
> level security in a repository, while gross-level read/write can
> be done in the server.