Rogan Dawes <lists@dawes.za.net> wrote:
quoted text
> 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.

quoted text
> 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.

quoted text
>> 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.

We already have to handle splitting PATH_TRANSLATED into a pair of
(GIT_DIR, command) so we can handle that for a GET.  We might as
well just use that very same code for POST to select the command.

Besides, by placing the command name into the URL server admins can
use regex filters in their configurations to control access.  If we
shove the command name into the body of a POST they cannot do this.

I can see sites wanting to offer anonymous smart fetch, but require
password protected smart push on the same repository URL.  Slapping
a directive like:

	<Location ~ ^/git/.*/receive-pack$>
		require valid-user
		...
	</Location>

Would easily make Apache implement this for us.  Most modern HTTP
servers should be able to be configured like this.

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.

-- 
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html