You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Subbu Allamaraju <su...@subbu.org> on 2011/06/16 01:51:39 UTC
Protocol upgrade requests
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
Re: Protocol upgrade requests
Posted by Leif Hedstrom <zw...@apache.org>.
On 06/15/2011 05:51 PM, Subbu Allamaraju 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?
Hi Subbu,
sorry for the late reply. Did you get this resolved yet? If not, I'll
try to take a look at it tomorrow, and see if there's anything to do
about conveying those headers upstream.
> On a broader note, can traffic server deal with protocol upgrade requests?
As far as I know, there's nothing in our code that deals with
"upgrades", but I'm not certain. Wouldn't upgrades be protocol specific
in general? ATS doesn't have any direct support for WebSocket's, yet at
least :).
Cheers,
-- Leif
Re: Protocol upgrade requests
Posted by sridhar basam <sr...@basam.org>.
On Wed, Jun 15, 2011 at 8:40 PM, Eric Balsa <er...@apache.org> 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 <er...@ericbalsa.com> 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?
>
That is right. Below are all the headers that the RFC defines as hop-by-hop
headers, these can't be forwarded to origin servers as per the spec.
Sridhar
The following HTTP/1.1 headers are hop-by-hop headers:
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- TE
- Trailers
- Transfer-Encoding
- Upgrade
Re: Protocol upgrade requests
Posted by Leif Hedstrom <zw...@apache.org>.
On 06/23/2011 01:40 PM, Subbu Allamaraju wrote:
> It becomes pass-through if the app server upgrades the protocol. Pl also see some threads (for example http://www.ietf.org/mail-archive/web/hybi/current/msg04739.html) in the hybi wg on workability and implications.
Well, ATS doesn't have a "pass through" mode in HTTP afaik (it.s all
request / response based, like HTTP is). There is however the CONNECT
method, but websockets doesn't use that afaik. With CONNECT, it becomes
basically a simple pass-through on the TCP level.
I have a vague recollection of someone looking at this before... I'm
wondering if it'd be possible for a plugin to detect an incoming request
as an upgrade to websockets, and turn it into a CONNECT request ? hmmmm.
-- Leif
Re: Protocol upgrade requests
Posted by Subbu Allamaraju <su...@subbu.org>.
It becomes pass-through if the app server upgrades the protocol. Pl also see some threads (for example http://www.ietf.org/mail-archive/web/hybi/current/msg04739.html) in the hybi wg on workability and implications.
Subbu
On Jun 23, 2011, at 12:24 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On 06/23/2011 12:47 PM, Subbu Allamaraju wrote:
>> To be more concrete, for an intermediary, Upgrade is hop-by-hop. But for a reverse proxy in front of a server that supports WebSockets, letting these headers through helps avoid putting newbie WebSocket servers on the web. Also see http://t.co/pUPJ82x for a concrete use case.
>
> Hmmm, but would simply passing through the Connection header be enough? Does the HTTP intermediary not have to be Websockets aware for this to work ? I guess I should really read up on Websockets ...
>
> -- Leif
>
Re: Protocol upgrade requests
Posted by Leif Hedstrom <zw...@apache.org>.
On 06/23/2011 12:47 PM, Subbu Allamaraju wrote:
> To be more concrete, for an intermediary, Upgrade is hop-by-hop. But for a reverse proxy in front of a server that supports WebSockets, letting these headers through helps avoid putting newbie WebSocket servers on the web. Also see http://t.co/pUPJ82x for a concrete use case.
Hmmm, but would simply passing through the Connection header be enough?
Does the HTTP intermediary not have to be Websockets aware for this to
work ? I guess I should really read up on Websockets ...
-- Leif
Re: Protocol upgrade requests
Posted by Subbu Allamaraju <su...@subbu.org>.
To be more concrete, for an intermediary, Upgrade is hop-by-hop. But for a reverse proxy in front of a server that supports WebSockets, letting these headers through helps avoid putting newbie WebSocket servers on the web. Also see http://t.co/pUPJ82x for a concrete use case.
Subbu
On Jun 15, 2011, at 5:40 PM, Eric Balsa <er...@apache.org> 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 <er...@ericbalsa.com> 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 <su...@subbu.org> 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
>>
Re: Protocol upgrade requests
Posted by Subbu Allamaraju <su...@subbu.org>.
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 <er...@apache.org> 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 <er...@ericbalsa.com> 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 <su...@subbu.org> 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
>>
Re: Protocol upgrade requests
Posted by Eric Balsa <er...@apache.org>.
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 <er...@ericbalsa.com> 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 <su...@subbu.org> 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
>