Re: Alt-Svc related Chromium bug report (proxy related)

On 20/04/2014 12:06 p.m., Mark Nottingham wrote:
> 
> On 18 Apr 2014, at 8:22 am, Erik Nygren wrote:
> 
>>> "Proxies MUST NOT change or append Alt-Svc values."
>>
>> Agreed.  I guess CDNs will need to remove Alt-Svc values that may be returned by an origin if they can't handle the upgrade.  This is a little unfortunate from a compatibility perspective.
> 
> Keep in mind that CDNs are *not* proxies as per the HTTP spec; they're gateways that happen to talk HTTP on the back end.
> 

The draft wording however is not limited to "proxies". Which was my
initial report of there being a problem.


Alt-Svc draft (editors copy from today):

3. The Alt-Svc HTTP Header Field:
"
  Intermediaries MUST NOT change or append Alt-Svc field values.
"


In HTTP/2 draft (editors copy from today):

2.2 Conventions and Terminology:
"
 intermediary:
    A "proxy", "gateway" or other intermediary as defined in Section
    2.3 of [HTTP-p1].
"


draft-ietf-httpbis-p1-messaging-26:

2.3. Intermediaries
"
  A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as
   an origin server for the outbound connection,
"


Therefore a CDN being an intermediary *MUST NOT* change the Alt-Svc
header, even to fix known problems. Despite being a gateway.



> 
>> It may also be worth us thinking through the Alt-Svc scenarios in the proxy world a little more carefully, perhaps with some concrete examples of flows to make sure we're on the same page.  For example, the upgrade case is fairly straight-forward:
>>
>> 1) Upgrade to HTTP/2-over-TLS through a proxy:
>>
>>         - client makes HTTP request through proxy (GET http://www.example.com/)
>>         - server returns AltSvc to the client via the proxy (Alt-Svc: http2=443)
>>         - client makes a HTTP connect request through the proxy (CONNECT www.example.com:443)
>>
>>
>> However, some of the other cases are less clear to me:
>>
>> 2) What happens for clients talking HTTP/2 to a proxy with the proxy talking HTTP/2 to the origin?  Would an ALTSVC frame referencing a different server and using TLS get passed through meaning that the client needs to now CONNECT through to do TLS?
> 
> I think the proxy would consume and potentially use the ALTSVC frame, since it's the one managing the connection to the server. Remember, ALTSVC doesn't change the origin.
> 
> 
>> 3) What happens with clients talking HTTP/1 to a proxy when the proxy is talking HTTP/2 to the origin and gets an ALTSVC frame pointing to a different host?  Presumably the proxy needs to drop it?
> 
> Think so.

Or not. Up to the proxy as recipient of the hop-by-hop frame.

> 
>>
>> Are there other similar scenarios we need to work through?
>>

ALTSVC frame from a proxy perspective is okay since it is defined with
hop-by-hop semantics.

The problem is interaction of the Alt-Svc HTTP/1 header since it is
end-to-end but places semantics of:

case A)
  bypassing an entire chain of proxies by diverting the client to an
entire alternate path.

case B)
 breaking connectivity, by informing the client about an Alt-Svc which
is impossibel for it to contact.

These could easily be encountered at an ISP where port 80 is firewalled
and HTTP delivered through an intermediary instead. Or at a CDN such as
teh one described where the gateway server offered diffrent services
than the internel origin node.


IMO the Alt-Svc header semantic needs to be redefined such that any
recipient can "terminate" it and contact the alternative service itself.
 Doing this will avoid problems from case A with a simple software
upgrade by any of the components in the chain. But also will work
through legacy intermediaries that dont understand it yet.

The blanket "MUST NOT" on changes to its values only works if the
intermediary which are in gateway situations are empowered to perform
the action the header indicated and/or drop it completely from the traffic.

Additional to that a gateway being in the position of an origin server
should be empowered to send its own Alt-Svc header. For the reason that
its very presence may be due to the backend server being obsolete
non-upgradable software.

Amos

Received on Sunday, 20 April 2014 06:37:22 UTC