These are indeed hop-by-hop headers. However, given that a generic intermediary like TS has no idea of the upgraded protocol, I don't see how it can ever support WebSockets and such protocols. That would be a shame and even operational pain for sites doing a mixture of WebSockets and HTTP as placing a proxy would break the upgrade.
By the way, there is huge opportunity for TS here. I'll check HTTP WG lists to find if this was ever discussed. Subbu On Jun 15, 2011, at 5:40 PM, Eric Balsa <[email protected]> wrote: > Subbu, we blast hop-by-hop headers (HTIF_HOPBYHOP / > MIME_FLAGS_HOPBYHOP) from the origin request. This happens in > HttpTransactHeaders::copy_header_fields so your origin will never see > those fields. > > Upgrade: & Connection: are defined as hop-by-hop header fields in the > TS source. Whether that is correct, i defer to the HTTP experts ;) > mnot? > > --Eric > > On Wed, Jun 15, 2011 at 5:38 PM, Eric Balsa <[email protected]> wrote: >> Subbu, we blast hop-by-hop headers (HTIF_HOPBYHOP / >> MIME_FLAGS_HOPBYHOP) from the origin request. This happens in >> HttpTransactHeaders::copy_header_fields so your origin will never see >> those fields. >> >> Upgrade: & Connection: are defined as hop-by-hop header fields in the >> TS source. Whether that is correct, i defer to the HTTP experts ;) >> mnot? >> >> --Eric >> >> On Wed, Jun 15, 2011 at 4:51 PM, Subbu Allamaraju <[email protected]> wrote: >>> I'm using TS as a reverse proxy to test protocol upgrade requests. The >>> client is sending the following headers >>> >>> Host:localhost >>> Connection:Upgrade >>> Origin:http://localhost >>> Sec-WebSocket-Key1:3B 5 40c3=2J712 >>> Sec-WebSocket-Key2:2z 79 9 9 2 8730 >>> Upgrade:WebSocket >>> >>> and I noticed that the proxy is not relaying Connection and Upgrade >>> headers. Is there a way to influence the list of headers? >>> >>> On a broader note, can traffic server deal with protocol upgrade requests? >>> >>> Thanks >>> Subbu >>
