Shawn O. Pearce wrote:
Rogan Dawes <lists@xxxxxxxxxxxx> 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.
Aha. So now I see the objective. I had misunderstood the intention to be
to *allow* caching of POST'ed resources.
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.
Right. Either with a "405 Method not supported", or a "404 Not found".
as I discovered.
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.
Fair enough. I had not thought about other uses for the input stream.
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.
Works for me!
Thanks for doing all the hard thinking for this feature :-)
Rogan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
