httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Upgrade Summary
Date Tue, 08 Dec 2015 10:07:24 GMT
Trying to summarize the status of the discussion and where the issues are with the current
Upgrade implementation.

Clarified:
A. any 100 must be sent out *before* a 101 response
B. request bodies are to be read in the original protocol, input filters like chunk can be
used, indeed are necessary, as if the request is being processed normally
C. if a protocol supports upgrade on request bodies is up to the protocol implementation and
needs to be checked in the "propose" phase

Open:
1. Protocols like Websocket need to take over the 101 sending themselves in the "switch protocol"
phase. (correct, Jacob?). Should we delegate the sending of the 101 to the protocol switch
handler?
2. General handling of request bodies. Options:
  a setaside in core of up to nnn bytes before switch invocation
  b do nothing, let protocol switch handler care about it
3. When to do the upgrade dance:
  a post_read_request: upgrade precedes authentication
  b handler: upgrade only honored on authenticated and otherwise ok requests
  c both: introduce separate hooks? have an additional parameter? more complexity
4. status code of protocol switch handler: if we move the task of 101 sending, the switch
handler might not do it and keep the connection on the "old" protocol. Then a connection close
is not necessary. So, we would do the close only when the switch handler returns APR_EOF.
5. Will it be possible to migrate the current TLS upgrade handling to this revised scheme?

Anything I missed?

PS. Re 5: with change 1+4, a TLS upgrade switcher could install an output filter, return and
have it being processed normally. The output filter would then send the 101 and do the TLS
handshake. Would that work?

> Am 08.12.2015 um 10:42 schrieb Stefan Eissing <stefan.eissing@greenbytes.de>:
> 
> 
>> Am 07.12.2015 um 23:42 schrieb Jacob Champion <champion.p@gmail.com>:
>> 
>> On 12/07/2015 02:30 PM, Bert Huijben wrote:
>>> Is this a h2 limitation or a mod_h2 limitation?
>>> 
>>> If I would like h2c upgrade from Subversion without an additional
>>> request I would have to send the upgrade request with a very short
>>> OPTIONS request that has a body.
>> 
>> The HTTP/2 spec (RFC 7540, sec 3.2) appears to allow the sending of a request body
in an h2c upgrade (h2 upgrades are prohibited). So it would appear to be a mod_http2 limitation
for now.
>> 
>> Hopefully Stefan can confirm tomorrow (it's pretty late in Germany).
> 
> It is possible, but difficult to do unless you can read the body and set it aside somewhere.
Which again imposes an arbitrary (for the client) limit. Experience shows that this leads
to design of clients that work will in developments, but then encounter requests usage/sites/servers
that have other limits and break.
> 
> If Apache accepts body lengths of up to 64KB (or something configurable) and some other
server implements 8K and some third 1MB, how will that help design of a client that, for some
reason, *wants* an upgrade to succeed? 
> 
> //Stefan
> 


Mime
View raw message