Re: character encoding in header fields, was: SPDY Header Frames

In message <CABP7RbfSMfNJBOkqRzsqdCOJ9Yi=9ZvjEOyW7efz0OwZOzgSzw@mail.gmail.com>
, James M Snell writes:

>> So how do you transport a 1.1 message inside 2.0 if it contains non-ASCII?
>> Treat the header field value as binary?

I think we should try to avoid mixing 1.1 and 2.0 that way.

It will require amazing amounts of verbiage to specify, and the
requirement of 2.0->1.1 downgrade will serverely curtail any attempt
at improvement in User-Agent, Cookie and other hacks.

If we take an approach where you cannot send 1.1 messages once you
upgrade a connection to 2.0 and cannot send 2.0 messages over
a 1.1 connection, what are the consequences ?

For direct client-server connections ?  No trouble.

A 1.1+2.0 dualmode server with 1.1+2.0 dualmode proxies/gateways/routers
in front of it ?  No trouble.

A 1.1+2.0 dualmode client with a 1.1+2.0 dual mode proxy and an
unknown server ?  Problem: The client cannot know if it can send
2.0 the proxy, because if the server can only do 1.1, it's stuck.

Solution 1:  Require a WKS record for HTTP/2.0, then the client
will know.  Works.  Some Well Known Downsides.  Not pretty.

Solution 2:  Make first request always be 1.1, tag reponse to
indicate tha 2.0 end-to-end is availble.  Works, but backwards
relative to end-goal, and prevents 1.1 from being killed off.

Solution 3:  Have the proxy return 2.0 status-code that says non
2.0-end-to-end-path available, client reissues request as 1.1 (on
diffenent connection) to proxy.  Works, but cost of (local) RTT's
first time (client can cache "no-2.0" bit for Host: value.)

Solution 4:  Always send first request in "pidgin-2.0" which
is a subset for which a trivial conversion to 1.1 can be defined.

Solution 5:  Give 2.0 a special verb "Encapsulated 1.1 request",
use this to send 1.1 request to proxy as binary blob.  If 2.0-e2e
not available, response will be (similarly encapsulated) 1.1 reponse.
If 2.0-e2e is available, reponse will be 2.0 plain reponse, and
client can send plain 2.0 thereafter.

I think I prefer solution 5.  It's easy to specify and implement,
and leaves us full freedom to make 2.0 better than 1.1.

-- 
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 Tuesday, 17 July 2012 15:47:44 UTC