Re: #541: CONTINUATION

In message <CAEn92TqRUkns8FLC_cLZ1xbh1iNpVexixZtawR1M7A5Eg8n-8g@mail.gmail.com>, Johnny Graetting
er writes:
>--001a11c1bbc0fda6b704fda1e67e
>Content-Type: text/plain; charset=UTF-8
>>
>> I thought about server visibility along these lines:
>>
>> In the case where the server is producing the basis for subsequent
>> requests (ie: links on a web-page), It is reasonable to expect the
>> web-designer to either theoretically or through tests confirm that
>> the links pass muster.
>>
>
>This is a tall order :) Consider even a mildly-dysfunctional organization
>with multiple teams owning siloed services operating over a shared cookie
>space. Throw in some AJAX requests with metadata made across those service
>boundaries for extra fun.

I have no problems with them having to think.  Their users/customers
will probably thank me for the better performance :-)

>In the other case, for instance where the client composes requests
>> based on some written API manual, I think the risk of huge HEADERS
>> is much more likely, but here again it doesn't matter who produces the
>> 413, the right person still receives it.
>
>How do I (as an API provider) discover that users are trying to use my
>service in a way I'm not currently supporting?

They'll complain to you ?

>A server can advertise a SETTINGS which is narrowly tuned to allow
>> all legitimate requests.
>
>In my experience, "narrow tuning to allow all legitimate requests" is an
>oxymoron :)

Well, your experience is obviously different from mine (proxied through
from the varnish users I talk with).  Their current response to the
lack of header-compression in HTTP/1.1 is to think a lot about how
big their ingoing and outgoing headers are, and how to use this to
discriminate DoS attacks.  Some of them have both upper and lower
bounds on valid requests.

>If I have intent to DoS, I'll send you exactly as much payload as you allow
>and no more. I'm not going to make it easy for you.

That's a lot easier for me to handle than the current drafts "any
number of CONTINUATION" packets with no specified timeout.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Monday, 7 July 2014 22:27:39 UTC