tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Accessing ServletContext from WebSocket endpoint
Date Sat, 07 Dec 2013 14:33:28 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Johan,

On 12/7/13, 4:30 AM, Johan Compagner wrote:
> On 7 December 2013 04:48, Christopher Schultz 
> <chris@christopherschultz.net>wrote:
> 
>>> because i only see currently api to get the HttpSession and
>>> then through that the ServletContext, problem is that there is
>>> no http session..
>> 
>> Aah... if there is no session, getHttpSession doesn't
>> automatically create one(). Boo.
> 
> 
> 
> and can it create one?
> 
> if a browser does a ws: request that will be first just a http
> request i guess that is then "upgraded" But in that first request
> can cookies be send over? Because if a websocket creates a http
> session then a jsessionid cookie must be set in the browser over
> the websocket request. And that jsession cookie must then be used
> by also normal http request a browser does to that server..

I'm no WebSocket expert, but the server has to first handle the
request as HTTP, and then upgrade it to WebSocket. The client can
establish a session first, then switch over to WebSocket and inherit
the session. I'm not sure if a "pure" WebSocket request can create a
session, since WebSocket is /not/ HTTP and therefore cookies are a bit
meaningless.

> problem is that i don't want to create a session, i just want to 
> ServletContext to read some files.

Yup, I get it.

> So something like:
> 
> EndpointConfig.getUserProperties().put("ServletContext",request.get
>
> 
Context());
> 
> That context can then just return an object which i need to cast
> and is then up to the container to provide.

I would lobby to have the container put the ServletContext into the
user properties -- just as you have above -- automatically during
connection set-up. There's nothing stopping Tomcat from doing that
right now, except that it would technically violate the spec and
introduce a non-standard vendor extension.

In this case, it's pretty clear that there is a quite desirable
feature missing from the spec and I think it might be reasonable to
violate it in this instance. I'd prefer to get Mark or Konstantin to
weigh-in on such a step, because it might set a bad precedent for Tomcat.

I'm certainly not going to commit that myself. :)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSozG4AAoJEBzwKT+lPKRYwHUP/1/rTzHMuYnG0PydbKAffDOo
5D+/YABdkxvmAs49MhVJyAFs9QLZn3NNmuNLoLnxirkAx2lG1RHxOrnS2VdHWrgE
g5WH5gEoMFyl52rl6QOiaXBFNDfBG7X3kqn8TzUWRMkoxZbwoN5GGG6Uhk3jWv9x
rWw/Bos7DqmssfrT+Y8Uk9+TbegkP0s9r56FY9PUvVPFSqjALX9sFd7WpzEPS8up
NwbAMJpiFydgIwXTmMy69kmTgcvYacfrcbyZuhQmV2PllfKDbNt4THxgop6TXlYp
KrDu3YzINf0DSFUgXNkjz5WGXnstLxjgn943YX54Xy5WBe9zxndOPedMBW/gHGM+
3LdlnPaOM8OGWSu0PZxXXuLIu+oWUcB8oUKaeIMa8Yv1Zb9WIPXe6m3AlAebkfDB
9yDFjcmWS5Fpc/qaXYqrxGMoVZc22GyhijdVn1jd7tK9TJAtGpoMQrQArfcQdJb3
qcifW5iHraTeE8iDSFIj94puv4XoE5u2GwRIx+qRs9mtHdu36GUj9GfVy6tEhsFA
eyhpw8cpM9DrePMus9O0OecYiTQv4eXDPhzYhj+zsjipmIhza7dzedIg12l+gnaY
TONnC3tXsOOl5cioJPaRgwl4jVKBrlg1xMIA937ncPiqKFoX//8nJq9LaCds7Vrq
33lj6jBuGweANjNxGsRC
=qMXW
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message