On Tue, Dec 8, 2015 at 11:00 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Apache httpd server offers limits on the number
> of incoming headers, the number of bytes in those headers, the number of
> bytes in the request line, the length of the URI. The maximum request body
> length. This is just one more limit, but not an actual *limitation*,
> because the request will be processed, simply not by changing protocols
> first, per RFC7230.
Agreed.
> On Tue, Dec 8, 2015 at 2:22 PM, Jacob Champion <champio...@gmail.com> wrote:
>>
>> 1) 100 Continue is sent whether the request is upgraded or not, which
>> makes it impossible to use a continue handshake to quickly determine upgrade
>> limits, and
100-continue is sent only if the client Expect's it, that's not mandatory.
>
>> 2) returning 413 during an upgrade would be ambiguous anyway. Is the 413
>> really related to the request target, or is it just because I tried to
>> upgrade and my request was temporarily limited?
>
> It never would. The possible results are the normal response in http/1.1
> protocol, or 426 to tell the client it still must change protocols first.
[]
>
> Our httpd http/1.1 server
> doesn't and cannot care, it can read-ahead the same network bucket it was
> going to read anyways, and let the new protocol handler decide, very early
> or very late in the cycle, whether the upgrade will happen. If it won't,
> httpd must continue to serve the response sticking to http/1.1.
Agreed, the module/handler can read the (HTTP/1) body if it needs it,
or ignore it, in any case the core must do the right thing for this
body, and if some Protocols was elected, do the 101 switch before any
response bytes.
For empty response (i.e. simple/single 101 response), couldn't the
module/handler simply flush?
If so, an output filter could do the job...
>
> RFC7230 is baked, expect no changes. The request (including 100-continue +
> body) is read, the protocol is switched if possible, otherwise the response
> is sent in http/1.1. Those are our constraints.
Agreed (again), and that constraints are not that bad ("normal"
Upgrade handshakes should not have a huge payload anyway), so we
should be able to do an Upgrade in a single round trip.
