[PATCH] httprepo: long arguments support (issue2126)

[Laurens Holst]

Op 27-3-2011 14:35, Steven Brown schreef:
> Idea: We limit the query string length to 2048 bytes, and switch to a POST
> request if it is longer. This will allow long arguments to be used with
> Apache and IIS.
>
> (See the default maxQueryString at
> http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering/requestLimits)
>
> If we get bug reports for more restrictive web servers, we can then further
> reduce the maximum query string size. Hopefully, by this time, most web
> servers will have the new configuration and will be unaffected.

I think it’s better to just always use GET, and only use the POST 
alternative when you get an HTTP 414 Request-URI Too Long[1] response. 
This means you will have an additional request in those cases, but they 
shouldn’t be common, and an extra request isn’t that big a deal (look 
how many requests the average web page makes).

I think this is a nicer approach than guessing and hard-coding a 
particular maximum size. This way existing server setups won’t be 
impacted, as the behaviour only changes for repositories that already 
have problems (which I think is a small minority?), and for those it 
changes for the better.

Note that the POST fallback does have the downside of possibly causing 
an authentication prompt, and an extra round-trip. To avoid this you can 
recommend users to change the server configuration to allow longer query 
strings (you already found the relevant setting for IIS), or to clean up 
the number of heads in the repository. As I argued in my other mail, I 
wouldn’t recommend making authentication exceptions for certain POST 
queries, that’s very risky.

If someone can come up with a way to change the current protocol so that 
it doesn’t create such long request URLs anymore, or to make it use 
multiple GET queries instead of a POST if it receives a 214 error (maybe 
at the expense of some efficiency), that would of course also be good. 
Because I think resorting to POST for this is more of a workaround than 
a real fix.

~Laurens

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.15

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6034 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110328/8e65ebf5/attachment.bin>