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 >
