HTTP headers on WebSocket connection

[Wojtek Erbetowski]

Is there a way to get to the request headers on WebSocket connection?

The WebSocket specification seem to handle them the same way the regular HTTP does - http://tools.ietf.org/html/rfc6455

but I can't find a way to acquire them.

Ideally I would see a method in ServerWebSocket class (for Groovy) called getHeaders:

server.websocketHandler { ServerWebSocket ws -> println ws.headers }

Cheers,

Wojtek

[Bartek Zdanowski]

What do you need this for?

I'm using HttpServer created from vertx instance

def httpServer = vertx.createHttpServer()

with routes set via RouteMatcher. Then in handler of every registered request I have HttpServerRequest with all stuff, especially with headers.

Do you consider this as I solution? I could post here some code.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję http://twitter.com/bartekzdanowski
Confitura 2013 - największa bezpłatna konferencja programistyczna - http://confitura.pl

[froz3n]

I'm not sure if we really need access to these headers. 

In addition, I'm not sure if the ws protocol actually allows for applications to pass data through header params. 

Either way, I can understand why some applications would like to have access to these details.

Now, one thing that is useful and that I don't think vertx websockets allows for is params passed through the query part of the URL. I might be wrong here, but the ws/wss url spec seems to allow for the same parts of a normal HTTP URL with the exception of # (anchors). I did a quick ws app to check if this was happening and I can only see the path part of the ws URL reflected in the ServerWebSocket. Shouldn't the query part be exposed through the interface?

Not having it simplifies the WebSocketMatcher implementation but it would be nice to at least have the URL params extracted and available on the request.

[Wojciech Erbetowski]

2013/3/30 froz3n <bmros...@gmail.com>

I'm not sure if we really need access to these headers. 

The need depends on the case. Since it's a part of WebSocket, then it's just simply missing in Vert.x, right?

Now, one thing that is useful and that I don't think vertx websockets allows for is params passed through the query part of the URL. I might be wrong here, but the ws/wss url spec seems to allow for the same parts of a normal HTTP URL with the exception of # (anchors). I did a quick ws app to check if this was happening and I can only see the path part of the ws URL reflected in the ServerWebSocket. Shouldn't the query part be exposed through the interface?

That's a completely different case. Still, Headers are part of WebSockets. Other frameworks seem to implement this feature, so I don't see the point in asking the user whether he actually needs them :-)

 

[Wojciech Erbetowski]

Hey Bartek,

2013/3/29 Bartek Zdanowski <bartek.z...@gmail.com>

What do you need this for?

I'm using HttpServer created from vertx instance

Yeah, HttpServer works fine in this particular case, but the WebSocketServer doesn't :-(

I need them for the same stuff you need headers in HTTP, e.g. session, client application distingish, ...

def httpServer = vertx.createHttpServer()

with routes set via RouteMatcher. Then in handler of every registered request I have HttpServerRequest with all stuff, especially with headers.

Do you consider this as I solution? I could post here some code.

But we have the communication based on WebSocket, currently based on JWebSocket.

My intention was to migrate to vert.x, which seemed quite cool, although this is a blocker for me.

Not using headers means changing the client applications (mobile apps) and that's a completely different story :-)

As far as I see most of stable WS implementations handle the headers, so it seems like an obvious miss.

[froz3n]

Wojciech,

Yes, you're right. Just open an issue on github and eventually someone will get to it (hopefully before 2.0 is released).

[Norman Maurer]

That may be me ;)

[Tim Fox]

On 30/03/13 11:07, Wojciech Erbetowski wrote:

2013/3/30 froz3n <bmros...@gmail.com>

I'm not sure if we really need access to these headers. 

The need depends on the case. Since it's a part of WebSocket, then it's just simply missing in Vert.x, right?

Not sure what you mean by "it's part of WebSocket". Can you clarify?

AIUI there is no way to set headers on a websocket in a browser using the standard WebSocket API so not sure what use this would be.

Now, one thing that is useful and that I don't think vertx websockets allows for is params passed through the query part of the URL. I might be wrong here, but the ws/wss url spec seems to allow for the same parts of a normal HTTP URL with the exception of # (anchors). I did a quick ws app to check if this was happening and I can only see the path part of the ws URL reflected in the ServerWebSocket. Shouldn't the query part be exposed through the interface?

That's a completely different case. Still, Headers are part of WebSockets. Other frameworks seem to implement this feature,

Really? And even if they did let you read headers on the server I'm not sure what the point would be as it's not possible to set them on the client, unless I'm missing something here...

so I don't see the point in asking the user whether he actually needs them :-)

 

[Tim Fox]

Really? Can you cite some references?

, so it seems like an obvious miss.

[Norman Maurer]

I think he refer to the http headers that are part of the handshake… If not then I have no clue ;)

Bye,

Norman

[Tim Fox]

On 30/03/13 20:38, Norman Maurer wrote:

I think he refer to the http headers that are part of the handshake�

Those headers are an implementation detail of the protocol, and not something that can be used to convey application level information, so I can't see any good reason to expose them.

If not then I have no clue ;)

Me neither :)

Bye,

Norman

Am 30.03.2013 um 21:28 schrieb Tim Fox <timv...@gmail.com>:

On 30/03/13 11:14, Wojciech Erbetowski wrote:

Hey Bartek,

2013/3/29 Bartek Zdanowski <bartek.z...@gmail.com>

What do you need this for?

I'm using HttpServer created from vertx instance

Yeah, HttpServer works fine in this particular case, but the WebSocketServer doesn't :-(

I need them for the same stuff you need headers in HTTP, e.g. session, client application distingish, ...

def httpServer = vertx.createHttpServer()

with routes set via RouteMatcher. Then in handler of every registered request I have�HttpServerRequest with all stuff, especially with headers.

Do you consider this as I solution? I could post here some code.

But we have the communication based on WebSocket, currently based on JWebSocket.

My intention was to migrate to vert.x, which seemed quite cool, although this is a blocker for me.

Not using headers means changing the client applications (mobile apps) and that's a completely different story :-)

As far as I see most of stable WS implementations handle the headers

Really? Can you cite some references?

, so it seems like an obvious miss.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

[Norman Maurer]

You can access them on the WebSocket JSR API … But to be honest I'm not a big fan of the API ;)

Am 30.03.2013 um 21:40 schrieb Tim Fox <timv...@gmail.com>:

On 30/03/13 20:38, Norman Maurer wrote:

I think he refer to the http headers that are part of the handshake…

Those headers are an implementation detail of the protocol, and not something that can be used to convey application level information, so I can't see any good reason to expose them.

If not then I have no clue ;)

Me neither :)

Bye,

Norman

Am 30.03.2013 um 21:28 schrieb Tim Fox <timv...@gmail.com>:

On 30/03/13 11:14, Wojciech Erbetowski wrote:

Hey Bartek,

2013/3/29 Bartek Zdanowski <bartek.z...@gmail.com>

What do you need this for?

I'm using HttpServer created from vertx instance

Yeah, HttpServer works fine in this particular case, but the WebSocketServer doesn't :-(

I need them for the same stuff you need headers in HTTP, e.g. session, client application distingish, ...

def httpServer = vertx.createHttpServer()

with routes set via RouteMatcher. Then in handler of every registered request I have HttpServerRequest with all stuff, especially with headers.

Do you consider this as I solution? I could post here some code.

But we have the communication based on WebSocket, currently based on JWebSocket.

My intention was to migrate to vert.x, which seemed quite cool, although this is a blocker for me.

Not using headers means changing the client applications (mobile apps) and that's a completely different story :-)

As far as I see most of stable WS implementations handle the headers

Really? Can you cite some references?

, so it seems like an obvious miss.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tim Fox]

On 30/03/13 20:42, Norman Maurer wrote:

You can access them on the WebSocket JSR API � But to be honest I'm not a big fan of the API ;)

Ok, but I'm guessing the vast majority of websockets users are using websockets from a browser where there is no API to set headers. Those users who are using a Java websocket client where headers can be set are probably in a very small minority, and if they write their app to rely on headers being set on the client then it's not going to be portable to browsers.

I'd say the request might have value but it's an edge case.

Am 30.03.2013 um 21:40 schrieb Tim Fox <timv...@gmail.com>:

On 30/03/13 20:38, Norman Maurer wrote:

I think he refer to the http headers that are part of the handshake�

Those headers are an implementation detail of the protocol, and not something that can be used to convey application level information, so I can't see any good reason to expose them.

If not then I have no clue ;)

Me neither :)

Bye,

Norman

Am 30.03.2013 um 21:28 schrieb Tim Fox <timv...@gmail.com>:

On 30/03/13 11:14, Wojciech Erbetowski wrote:

Hey Bartek,

2013/3/29 Bartek Zdanowski <bartek.z...@gmail.com>

What do you need this for?

I'm using HttpServer created from vertx instance

Yeah, HttpServer works fine in this particular case, but the WebSocketServer doesn't :-(

I need them for the same stuff you need headers in HTTP, e.g. session, client application distingish, ...

def httpServer = vertx.createHttpServer()

with routes set via RouteMatcher. Then in handler of every registered request I have�HttpServerRequest with all stuff, especially with headers.

Do you consider this as I solution? I could post here some code.

But we have the communication based on WebSocket, currently based on JWebSocket.

My intention was to migrate to vert.x, which seemed quite cool, although this is a blocker for me.

Not using headers means changing the client applications (mobile apps) and that's a completely different story :-)

As far as I see most of stable WS implementations handle the headers

Really? Can you cite some references?

, so it seems like an obvious miss.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

[froz3n]

On Sunday, March 31, 2013 3:04:16 PM UTC-4, Tim Fox wrote:

On 30/03/13 20:42, Norman Maurer wrote:

You can access them on the WebSocket JSR API � But to be honest I'm not a big fan of the API ;)

Ok, but I'm guessing the vast majority of websockets users are using websockets from a browser where there is no API to set headers. Those users who are using a Java websocket client where headers can be set are probably in a very small minority, and if they write their app to rely on headers being set on the client then it's not going to be portable to browsers.

Tim, you are correct about the headers. There's this in the RFC, (page 18), which I thought implied that extra headers would be sent up.

 The request MAY include any other header fields, for example,

 cookies [RFC6265] and/or authentication-related header fields

 such as the |Authorization| header field [RFC2616], which are

 processed according to documents that define them.

Unfortunately, the *protocol* spec includes this but there is nothing in the API defined for it in http://dev.w3.org/html5/websockets/, and most probably no browser or client that supports it.

The query part of the URL though is passed by browsers (at least chrome: see network header below), it is accounted for in the API and as such it should be available for usage on the server side.

1. Request URL:
   ws://localhost:8080/gittalk/crazyfrozenpenguin?foo=123
2. Request Method:
   GET
3. Status Code:
   101 Switching Protocols
4. Request Headersview source
1. Cache-Control:
   no-cache
2. Connection:
   Upgrade
3. Cookie:
   JSESSIONID=dummy
4. Host:
   localhost:8080
5. Origin:
   http://localhost:8080
6. Pragma:
   no-cache
7. Sec-WebSocket-Extensions:
   x-webkit-deflate-frame
8. Sec-WebSocket-Key:
   1H1QctdonPMBwpvrW+3OTg==
9. Sec-WebSocket-Version:
   13
10. Upgrade:
    websocket
5. Query String Parametersview sourceview URL encoded
1. foo:
   123
6. Response Headersview source
1. Connection:
   Upgrade
2. Sec-WebSocket-Accept:
   V+cWd21Mymyd06h8eEc8bOyqLKI=
3. Upgrade:
   websocket

[Wojciech Erbetowski]

2013/3/30 froz3n <bmros...@gmail.com>

Yes, you're right. Just open an issue on github and eventually someone will get to it (hopefully before 2.0 is released).

Thanks, that's the answer I needed :-)

If someone else is interested in the subject, follow the issue here - https://github.com/vert-x/vert.x/issues/547

[Wojciech Erbetowski]

2013/3/31 Tim Fox <timv...@gmail.com>

On 30/03/13 20:42, Norman Maurer wrote:

You can access them on the WebSocket JSR API … But to be honest I'm not a big fan of the API ;)

Ok, but I'm guessing the vast majority of websockets users are using websockets from a browser where there is no API to set headers. Those users who are using a Java websocket client where headers can be set are probably in a very small minority, and if they write their app to rely on headers being set on the client then it's not going to be portable to browsers.

I'd say the request might have value but it's an edge case.

Now I understand the motivation :-) Although if an application uses Basic Auth or cookies they should* be populated to WS handshake as well

( * - but I googled out some issues with that as well).

So headers should be avoided at this moment in client apps :-(

But how do you maintain the authentication across the rest of the application?

Start the WS conversation with re-sending some authentication token acquired earlier by HTTP?

[Wojciech Erbetowski]

2013/3/30 Tim Fox <timv...@gmail.com>

As far as I see most of stable WS implementations handle the headers

Really? Can you cite some references?

Just like I said - as far as I see. We grabbed the first two Java_WebSocket and SocketRocket for iOS.

Both supported headers, so I didn't even think that using them might be an issue.

When I got to the problem at Vert.x - searching for WS headers showed couple more libs with such support (socket.io, PlayFramework 2).

At least mentioned on the www, I haven't really tried if they actually do.

That is what I meant, but I'm not sure if that's even close to the truth. 

I didn't mean to offend anyone. Sorry if I did.

[Yangming Huang]

Disagree! We need the headers to get "Referer" and "User-Agent" which majority of the browsers will sent automatically without user interfere.

The problem of Vertx is it has made too much assumption and has become less flexible. For example HttpServerRequest.query will decode the queryString automatically where I have another URL encoded as a value and has been mixtured with other queryString (e.g. http://our.domain/?url=http://forward.domain/?somekey=somevalue ) then it's hard to parse the url out of the queryString.

Another example is it makes all the headers lower-case as it's defined in RFC that headers are case-insensitive, but there is chance the browser does not comply to RFC. Vertx wants to save the trouble for user, but it's just a simple headers['someheader'].toLowerCase for the user to do themselves, where in the meanwhile they gain flexibility. I'd rather being provided a function called request.headersInLowerCase where the output is always lower-case, and a regular request.headers, so it's understandable and flexible to the users.

I appreciate that Vertx is trying to make the api as simple as possible, and have lots of work done for the user, but it should always leave an option for the user to do it manually.

On Sunday, March 31, 2013 3:04:16 PM UTC-4, Tim Fox wrote:

[Tim Fox]

I'm not sure whether you're referring to 1.x or 2.x but I will try to
answer your points

On 10/06/13 15:31, Yangming Huang wrote:
> Disagree! We need the headers to get "Referer" and "User-Agent" which
> majority of the browsers will sent automatically without user interfere.

Vert.x 2.0 supports getting headers from a server side websocket

>
> The problem of Vertx is it has made too much assumption and has become less
> flexible. For example HttpServerRequest.query will decode the queryString

It's actually the JDK class URI which does the decoding automatically,
but if you don't like this (and I think you will be in a minority) then
the uri() method should give you the raw uri and you can extract the
unencoded path yourself.

> automatically where I have another URL encoded as a value and has been
> mixtured with other queryString (e.g.
> http://our.domain/?url=http://forward.domain/?somekey=somevalue ) then it's
> hard to parse the url out of the queryString.
>
> Another example is it makes all the headers lower-case as it's defined in
> RFC that headers are case-insensitive, but there is chance the browser does
> not comply to RFC. Vertx wants to save the trouble for user, but it's just
> a simple headers['someheader'].toLowerCase for the user to do themselves,

(The header decoding is actually done by Netty)

But, it's not as simple as that. For example, the browser might have set
the header as:

'Content-Type', 'content-type', 'content-Type', etc

Allowing you to do: headers().get('content-type') prevents you from
having to lower case the *entire map* yourself - which would be an
intensive operation - just lower casing a single key won't work

> where in the meanwhile they gain flexibility. I'd rather being provided a
> function called request.headersInLowerCase where the output is always
> lower-case, and a regular request.headers, so it's understandable and
> flexible to the users.

That would impose a significant performance penalty as we'd have to
decode and maintain the headers in raw form AND then convert them again
when you called request.headersInLowerCase.

I think most people would like the current behaviour anyway and
penalising them for a minority isn't the way to go imho.

>
> I appreciate that Vertx is trying to make the api as simple as possible,
> and have lots of work done for the user, but it should always leave an
> option for the user to do it manually.
>
> On Sunday, March 31, 2013 3:04:16 PM UTC-4, Tim Fox wrote:
>> On 30/03/13 20:42, Norman Maurer wrote:
>>

>> You can access them on the WebSocket JSR API � But to be honest I'm not

>> a big fan of the API ;)
>>
>>
>> Ok, but I'm guessing the vast majority of websockets users are using
>> websockets from a browser where there is no API to set headers. Those users
>> who are using a Java websocket client where headers can be set are probably
>> in a very small minority, and if they write their app to rely on headers
>> being set on the client then it's not going to be portable to browsers.
>>
>> I'd say the request might have value but it's an edge case.
>>
>>
>> Am 30.03.2013 um 21:40 schrieb Tim Fox <timv...@gmail.com <javascript:>>:
>>
>> On 30/03/13 20:38, Norman Maurer wrote:
>>

>> I think he refer to the http headers that are part of the handshake�

>>
>>
>> Those headers are an implementation detail of the protocol, and not
>> something that can be used to convey application level information, so I
>> can't see any good reason to expose them.
>>
>> If not then I have no clue ;)
>>
>>
>> Me neither :)
>>
>>
>> Bye,
>> Norman
>>

>> Am 30.03.2013 um 21:28 schrieb Tim Fox <timv...@gmail.com <javascript:>>:
>>
>> On 30/03/13 11:14, Wojciech Erbetowski wrote:
>>
>> Hey Bartek,
>>

>> 2013/3/29 Bartek Zdanowski <bartek.z...@gmail.com <javascript:>>

>>
>>> What do you need this for?
>>> I'm using HttpServer created from vertx instance
>>>
>> Yeah, HttpServer works fine in this particular case, but the
>> WebSocketServer doesn't :-(
>> I need them for the same stuff you need headers in HTTP, e.g. session,
>> client application distingish, ...
>>
>> def httpServer = vertx.createHttpServer()
>>>
>>> with routes set via RouteMatcher. Then in handler of every registered

>>> request I have�HttpServerRequest with all stuff, especially with headers.

>>>
>>> Do you consider this as I solution? I could post here some code.
>>>
>> But we have the communication based on WebSocket, currently based on
>> JWebSocket.
>> My intention was to migrate to vert.x, which seemed quite cool, although
>> this is a blocker for me.
>> Not using headers means changing the client applications (mobile apps) and
>> that's a completely different story :-)
>>
>> As far as I see most of stable WS implementations handle the headers
>>
>>
>> Really? Can you cite some references?
>>
>> , so it seems like an obvious miss.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to vertx+un...@googlegroups.com <javascript:>.

>> For more options, visit https://groups.google.com/groups/opt_out.

>> �
>> �

>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to vertx+un...@googlegroups.com <javascript:>.

>> For more options, visit https://groups.google.com/groups/opt_out.

>> �
>> �

>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to vertx+un...@googlegroups.com <javascript:>.

>> For more options, visit https://groups.google.com/groups/opt_out.

>> �
>> �

>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to vertx+un...@googlegroups.com <javascript:>.

>> For more options, visit https://groups.google.com/groups/opt_out.

>> �
>> �

>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to vertx+un...@googlegroups.com <javascript:>.

>> �
>> �
>>
>>
>>

[Yangming Huang]

Thanks Tim, this is very helpful, I'll try to upgrade to 2.x then.

For the headers, I really mean the headers written back in the response, the way headers being lower-cased in request is fine for me (and the majority, you are right about this).

>> You can access them on the WebSocket JSR API � But to be honest I'm not

>> a big fan of the API ;)
>>
>>  
>> Ok, but I'm guessing the vast majority of websockets users are using
>> websockets from a browser where there is no API to set headers. Those users
>> who are using a Java websocket client where headers can be set are probably
>> in a very small minority, and if they write their app to rely on headers
>> being set on the client then it's not going to be portable to browsers.
>>
>> I'd say the request might have value but it's an edge case.
>>
>>  
>>   Am 30.03.2013 um 21:40 schrieb Tim Fox <timv...@gmail.com <javascript:>>:
>>
>>   On 30/03/13 20:38, Norman Maurer wrote:
>>  

>> I think he refer to the http headers that are part of the handshake�

>>
>>
>> Those headers are an implementation detail of the protocol, and not
>> something that can be used to convey application level information, so I
>> can't see any good reason to expose them.
>>
>>   If not then I have no clue ;)
>>
>>
>> Me neither :)
>>
>>  
>>   Bye,
>> Norman
>>
>>   Am 30.03.2013 um 21:28 schrieb Tim Fox <timv...@gmail.com <javascript:>>:
>>
>>   On 30/03/13 11:14, Wojciech Erbetowski wrote:
>>  
>> Hey Bartek,
>>
>>   2013/3/29 Bartek Zdanowski <bartek.z...@gmail.com <javascript:>>
>>  
>>>   What do you need this for?
>>> I'm using HttpServer created from vertx instance
>>>  
>> Yeah, HttpServer works fine in this particular case, but the
>> WebSocketServer doesn't :-(
>>   I need them for the same stuff you need headers in HTTP, e.g. session,
>> client application distingish, ...
>>
>>    def httpServer = vertx.createHttpServer()
>>>  
>>>   with routes set via RouteMatcher. Then in handler of every registered

>>> request I have�HttpServerRequest with all stuff, especially with headers.

>>>
>>>   Do you consider this as I solution? I could post here some code.
>>>  
>> But we have the communication based on WebSocket, currently based on
>> JWebSocket.
>> My intention was to migrate to vert.x, which seemed quite cool, although
>> this is a blocker for me.
>> Not using headers means changing the client applications (mobile apps) and
>> that's a completely different story :-)
>>
>>   As far as I see most of stable WS implementations handle the headers
>>    
>>
>> Really? Can you cite some references?
>>
>>     , so it seems like an obvious miss.
>>
>>     --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to vertx+un...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.

>> �
>> �

>>
>>
>>  
>>   --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to vertx+un...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.

>> �
>> �

>>
>>  
>>   --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to vertx+un...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.

>> �
>> �

>>
>>
>>  
>>   --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to vertx+un...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.

>> �
>> �

>>
>>  
>>   --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to vertx+un...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.

>> �
>> �
>>
>>
>>

[Tim Fox]

On 10/06/13 17:22, Yangming Huang wrote:
> Thanks Tim, this is very helpful, I'll try to upgrade to 2.x then.
>
> For the headers, I really mean the headers written back in the response,

Hmm, I don't think this happens in 2.x, but you should check :)

>>>> You can access them on the WebSocket JSR API � But to be honest I'm

>> not
>>>> a big fan of the API ;)
>>>>
>>>>
>>>> Ok, but I'm guessing the vast majority of websockets users are using
>>>> websockets from a browser where there is no API to set headers. Those
>> users
>>>> who are using a Java websocket client where headers can be set are
>> probably
>>>> in a very small minority, and if they write their app to rely on
>> headers
>>>> being set on the client then it's not going to be portable to browsers.
>>>>
>>>> I'd say the request might have value but it's an edge case.
>>>>
>>>>
>>>> Am 30.03.2013 um 21:40 schrieb Tim Fox <timv...@gmail.com<javascript:>>:
>>>>
>>>> On 30/03/13 20:38, Norman Maurer wrote:
>>>>

>>>> I think he refer to the http headers that are part of the handshake�

>>>>
>>>>
>>>> Those headers are an implementation detail of the protocol, and not
>>>> something that can be used to convey application level information, so
>> I
>>>> can't see any good reason to expose them.
>>>>
>>>> If not then I have no clue ;)
>>>>
>>>>
>>>> Me neither :)
>>>>
>>>>
>>>> Bye,
>>>> Norman
>>>>
>>>> Am 30.03.2013 um 21:28 schrieb Tim Fox <timv...@gmail.com<javascript:>>:
>>>>
>>>> On 30/03/13 11:14, Wojciech Erbetowski wrote:
>>>>
>>>> Hey Bartek,
>>>>
>>>> 2013/3/29 Bartek Zdanowski <bartek.z...@gmail.com <javascript:>>
>>>>
>>>>> What do you need this for?
>>>>> I'm using HttpServer created from vertx instance
>>>>>
>>>> Yeah, HttpServer works fine in this particular case, but the
>>>> WebSocketServer doesn't :-(
>>>> I need them for the same stuff you need headers in HTTP, e.g.
>> session,
>>>> client application distingish, ...
>>>>
>>>> def httpServer = vertx.createHttpServer()
>>>>>
>>>>> with routes set via RouteMatcher. Then in handler of every
>> registered

>>>>> request I have�HttpServerRequest with all stuff, especially with

>> headers.
>>>>> Do you consider this as I solution? I could post here some code.
>>>>>
>>>> But we have the communication based on WebSocket, currently based on
>>>> JWebSocket.
>>>> My intention was to migrate to vert.x, which seemed quite cool,
>> although
>>>> this is a blocker for me.
>>>> Not using headers means changing the client applications (mobile apps)
>> and
>>>> that's a completely different story :-)
>>>>
>>>> As far as I see most of stable WS implementations handle the headers
>>>>
>>>>
>>>> Really? Can you cite some references?
>>>>
>>>> , so it seems like an obvious miss.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>> Groups
>>>> "vert.x" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>> an
>>>> email to vertx+un...@googlegroups.com <javascript:>.
>>>> For more options, visit https://groups.google.com/groups/opt_out.

>>>> �
>>>> �

>>>>
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>> Groups
>>>> "vert.x" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>> an
>>>> email to vertx+un...@googlegroups.com <javascript:>.
>>>> For more options, visit https://groups.google.com/groups/opt_out.

>>>> �
>>>> �

>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>> Groups
>>>> "vert.x" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>> an
>>>> email to vertx+un...@googlegroups.com <javascript:>.
>>>> For more options, visit https://groups.google.com/groups/opt_out.

>>>> �
>>>> �

>>>>
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>> Groups
>>>> "vert.x" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>> an
>>>> email to vertx+un...@googlegroups.com <javascript:>.
>>>> For more options, visit https://groups.google.com/groups/opt_out.

>>>> �
>>>> �

>>>> �
>>>> �
>>>>
>>>>
>>>>
>>

[Yangming Huang]

Looks like 2.0 is still in beta, I am looking forward to the stable version. Thanks Tim.