Bert, why can't you use h2c in direct mode? I assume you could store server support for this in the checkout meta data somewhere.
//Stefan > Am 08.12.2015 um 11:30 schrieb Bert Huijben <[email protected]>: > >> -----Original Message----- >> From: Stefan Eissing [mailto:[email protected]] >> Sent: dinsdag 8 december 2015 11:07 >> To: [email protected] >> Subject: Upgrade Summary >> >> 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? > > If possible I would recommend avoiding this. I think the original protocol > should setup the response and then the final protocol should somehow be able > to annotate this. > > The problems we try to solve now originate from the problem of doing things > different in different protocol handlers, while in theory many upgrades are > very similar. > > The TLS and H2C upgrades both begin in one form and end in a different form. > Websockets are kind of different in that they require a bad request response > in a specific case. I'm not sure in which protocol this error needs to be > send though. > > In TLS and H2C further errors can always be produced in the new protocol, so > when the handshake succeeds things can just go on. > >> 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 > > For Subversion to be able to use upgrade we would need to support a small > body on a request (few hundred bytes. Content-Length header provided). > > During our current (already optimized) handshake all requests have bodies, > and introducing an additional request just to upgrade will slow things down > quite measurable on operation like 'svn log', that are mostly bound by the > handshake time. > > We can't just switch the handshake to be something else... our handshake was > built upon WEBDAV and DELTA/V. We added several headers to avoid many > requests we previously performed, but we can't move away from that initial > OPTIONS request without slowing down against all older servers. > > Bert
