On 12/08/2015 02:00 PM, William A Rowe Jr 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.
I agree with your point -- that's what I was trying to point out with my
OP -- but I think general-purpose clients that are trying to ensure
their upgrades succeed as quickly as possible, as often as possible, and
are thwarted in that by an invisible request body limit, might consider
it a limitation. That the request succeeds is not necessarily their only
design goal.
As I'll point out again in closing, h2c isn't defined by RFC7230, and if
it decides to ignore requests with bodies, that's up to mod_http2 and
other implementations. But RFC7230 has nothing to say to h2c on this,
and rather encourages protocol implementors to accept already-read C-L
or T-E: chunked request bodies in a hand-over into their upgraded protocol.
Agreed. And like I said in my response to Yann, if it turns out that the
arbitrary upgrade-body-limit for h2c can be done away with entirely, an
official addition to HTTP would be completely unnecessary.
There is no need for the client to determine the upgrade limit, because
the body of the request is sent. If the server -arbitrarily- chooses to
satisfy it, there will be a 101 following the body transmission. But
the spec makes absolutely clear that it is the server's prerogative to
upgrade or not, irrespective of the particular upgrade requested.
If the server demands that the upgrade happen, before a request can be
honored, it must reply with a 426 until the client offers to upgrade.
If the client demands that the upgrade happen, it must perform the
simplest applicable request (e.g. OPTIONS *) with the desired upgrade
semantics and verify that the upgrade occurred.
Stefan is, I think, adding more shades of grey here. OPTIONS * is the
most likely upgrade to succeed, but also guarantees the addition of an
"unnecessary" (depending on your point of view) round-trip. Clients may
be willing to make a trade-off in initial success rate for an average
increase in performance, but not if the server implementations are so
different that their success rate plummets.
Whether this is enough of a concern to "fix" is a matter of opinion. But
it appears that there has already been an agreement of sorts to reject
h2c response bodies from the major implementors, if I understood Stefan
correctly, so they at least are concerned. It would be nice to read that
conversation.
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.
I'm not sure I understand what you mean. My point was simply that while
a pure HTTP/1.1 client implementation can try to optimize its "limits
discovery" through the use of a 100-continue handshake, and immediately
making adjustments if a 4xx comes back, clients have no way to apply the
same discovery to an artificial limit on upgrade-requests.
And again, whether such a limit is justified to begin with still remains
to be seen, I think.
Define complex, robust. Request (upgrade: somespec) -> 100 continue ->
request body <- [ http/1.1 response | 101 - switching protocols <- new
protocol response ].
Hopefully I've clarified what I mean by this -- not "robust" in terms of
whether the request breaks or not, but "robust" in terms of a high
success rate for optimally-performant upgrades to h2c.
--Jacob
