[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