[PATCH] Make sure whole bundle content is read before replying to web unbundle command

Mads Kiilerich mads at kiilerich.com
Sun Oct 19 13:57:19 CDT 2008


Matt Mackall wrote, On 10/15/2008 01:23 AM:
>>> Interesting. How much harder would it be to make the client handle the
>>> exception instead? We'd much rather take load off the server side
> So I take it your answer is "much harder". Fair enough.
>   

YMMV ;-)

>> We could define that the current server behaviour is the right one. 
>> Clients could and should first post a unbundle command without content. 
>> It should be able to handle authentication error codes in that 
>> situation. If it succeeds then it can post the real unbundle. And if 
>> that fails then it is free to crash badly.
>>
>> But on the third side: How much load is there to take off from the 
>> server side? Is it worth caring about DOS by uploads which will be 
>> cancelled immediately? It is probably much easier to DOS the same 
>> bandwith by downloads which even uses more CPU.
>>     
>
> It's less about intentional DOS attacks than users being clueless. Oh,
> did I just push a gigabyte of data to the wrong address? Silly me!
>   

Personally I would gladly provide the credentials to the wrong address. 
I will only turn off the auto pilot when I am told that the repos are 
unrelated. And in that case hgweb.protocol.unbundle already has drained 
the incoming bundle. And if I upload so much data that it matters then 
it will take so much time that I will be impatient and cancel the 
operation anyway.

I suggest first applying the patch to make the currently expected (and 
tested) behaviour consistent - with both consistent handling of bundles 
in different code paths and with consistently reproducible behaviour.

Protection from clueless users is a nice feature which can be added later.

If you prefer the current nondeterministic behaviour then so be it. But 
in that case please remove the test that fails.

/Mads

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3435 bytes
Desc: S/MIME Cryptographic Signature
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20081019/e226fd90/attachment.bin 


More information about the Mercurial-devel mailing list