Originally by @jdahlstrom

This is, unfortunately, by design. The Websocket protocol is completely separate from HTTP and does not have anything resembling HTTP requests and responses (excepting the initial handshake which looks like HTTP for compatibility reasons.) So, for example, setting response headers would make little sense.

With the various AJAX-based push fallbacks such as streaming and long-polling the request and response are there and could be exposed via getCurrent*() but they don't necessarily work intuitively. For instance, the same AJAX response can be used to stream multiple logical response messages, so you couldn't set headers for the individual messages.

Is this simply a documentation issue or do you have a use case in mind that could somehow be implemented even given the above limitations?

Originally by tleveque

My problem is that I need to create and read cookies.
How can I do that now?

Originally by @jdahlstrom

We could expose a cookie API in Page or WebBrowser that uses client RPC to get/set cookies via JavaScript. However, HttpOnly cookies wouldn't be accessible that way.

Originally by tleveque

Not sure what you mean by httpOnly cookies (versus what?), but you really need to implement that before the final version of version 7.1 otherwise it will break a lot of application without real workaround.

Originally by @jdahlstrom

https://www.owasp.org/index.php/HttpOnly

Basically, if the HttpOnly optional attribute is present in Set-Cookie (and the browser supports the attribute), the cookie in question cannot be accessed in the browser via JavaScript.

A workaround is, of course, not using push. Seriously, depending on when you need to set/read cookies, you might be able to set PushMode.DISABLED for the duration and enable it after you're done. Also, do note that VaadinRequest and VaadinResponse are available in UI.init() even with push (as the push connection is not yet open at that point.)

One way to implement this that works with HttpOnly cookies would be to ask the browser to make a regular AJAX request just for reading/setting cookies even when push is enabled. This wouldn't be hard to implement, actually. However, the API would need to be asynchronous. This is actually a good use case for the RPC-with-return-values feature we're currently prototyping for 7.2.

Anyway, this is an unfortunate limitation in the current implementation, but breaks no legacy code, so I'm changing this ticket into an enhancement request. We'll need to think about this a bit.

Originally by @Legioth

One potential way of fixing this would be as described in #12518.

This would still not have cookies available in background threads, but they would be available in e.g. click handlers and other events directly initiated by the client.

Originally by @wolfie

There is no reliable way to fix this directly. There were a few options we considered:

1. Check that the latest versions of servlet containers would allow us to simply bypass the usage of FakeHttpSession and operate directly on the HttpSession.
2. Add some kind of mechanism to link the initial HttpSession with FakeHttpSession.

We deemed that these solutions would be too hazardous to implement, since the long-term side-effects in all corner cases are unknown. Some quick prototypes seemed to work, but we had no chance of verifying those. Also, we would've needed to diverge our fork of Atmosphere even further, which we are very reluctant to do, considering we still need to keep up to date with the upstream in the future.

This ticket and a related #11721 (both which stem from very related issues - not being able to access the original http session/http request objects) will be closed with the resolution "wontfix". Instead, this issue was decided to be fixed with the help of #12518 (so you should follow and vote on that ticket instead).

We don't want to fix the individual symptoms, but we'd rather work around the issue by providing a more rigorous solution to this, and any related problems.

Originally by @Artur-

Updated summary to reduce confusion. This issue is only related to websockets, not long-polling or streaming (or any HTTP request based push mechanism)

Originally by sv

Is it bad to do it like that ?

JavaScript.getCurrent().execute("document.cookie= .....

for non HttpOnly cookies

Originally by @Legioth

Using Vaadin's JavaScript class to set non-HttpOnly cookies should work perfectly fine, though you might need to be careful with escaping the cookie value.

For reading cookie values, you'd need to use JavaScript.addFunction to add export a function that sends the value back and then use JavaScript.execute to run that exported function.

Originally by @mstahv

For those trying to find a simple way to use cookies, check out BrowserCookie class in Viritin. It hides complexities of both the JavaScript API and cookie "API" behind a simple helper. Works with both push and normal communication.

Originally by @Artur-

In Vaadin 7.6 you can use WEBSOCKET_XHR to get around this limitation. In that case, only explicitly pushed messages will go through the websockets connection and user interactions as XHR

I just beat my head against this for a half hour.

How about at least updating the Javadoc for VaadinService.getCurrentResponse() so others don't have to do the same??

Hey @archiecobbs, what did you eventually end up doing?

I agree with updating the Javadoc.

@afspear it's not addressed yet. For now, users in my application have to login again after the session times out.