Comments (9)
The cookie issue seems to be an old bug in the CookieDecoder class being used: netty/netty#649
the problem is that Chrome does not send expires back to the server when requesting.
from vertx-web.
In M2, it seems like we're on an old version of netty: 4.0.24.Final . We should upgrade to
4.0.25.Final . The CookieDecoder class that's currently being used, is not present in netty trunk at all. It seems they became aware of the problems with it.
from vertx-web.
Yes, we should change the cookiehandler to only write cookies back if they have changed
from vertx-web.
The problem with knowing if they've changed, is that the browser only sends back the name and value, it doesn't send the path or expiry / max-age.
So we can determine if the name / value have changed, but if the expiry / path have changed, we won't be able to tell that. (If a user is logging out, the cookie would be deleted by setting max-age to a negative value).
I think a better solution is to provide a readonly Collection<Cookie>
for reading the cookies, and store a separate List<Cookie>
for the ones which are added via context.addCookie
. That way, we only send back the ones which are added to the List
and don't touch the readonly ones.
Would you like a PR that does that?
from vertx-web.
Actually, a simpler solution would be to store a boolean isDirty
flag in CookieImpl
. At the start of the request, cookie.setDirty(false)
is called on each cookie which is read from the request. Using any of the setters on the cookie would reset isDirty
to true. Then, at the end, any cookies which weren't initially present in the map, or which have the isDirty
set to true, are added back to response.
How does that sound?
from vertx-web.
@aliakhtar Sounds good. This will take users off the annoyng copying back and forward.
But how the user will be able to get unmodified request-headers?
We can only modify response headers without affecting request ones.
from vertx-web.
I've made some changes in the socksjs branch (just waiting for vietj to review it, then I can merge it in ;) )
from vertx-web.
Looks nice. At this line though: https://github.com/vert-x3/vertx-apex/blob/ac7cd0b4152f1daf53986ca350535549389fc48f/src/main/java/io/vertx/ext/apex/impl/CookieImpl.java#L36
You're setting changed=true
within the constructor. Wouldn't this mean that when the CookieHandler reads the cookies from the response, the cookies would be generated with changed=true
even if they aren't modified?
Perhaps have a setChanged
method present in there, so that CookieHandler can set it to false after first reading the cookie, and only subsequent modifications switch it back on.
from vertx-web.
That constructor is only used before you add a new cookie, in which case you want it to be sent out in the response.
from vertx-web.
Related Issues (20)
- HttpContext.fail() does not release the connection when invoked in SEND_REQUEST phase
- WebClient: NPE on misformatted Date or Expires header HOT 1
- absoluteURI is null when host header is missing HOT 2
- Issue with POST request hanging indefinitely in Vert.x Web HOT 3
- CSRF validation fails because CSRFHandler updates the session AFTER the session is already flushed HOT 1
- SockJS Event Bus Bridge does not keep web sessions alive for clustered session managers
- When upgrade vertx4, the path cannot support colon, and vertx 3 is ok HOT 1
- Use the new `OAuth2AuthorizationURL` in `OAuth2AuthHandler.extraParams`
- Reduce heavy atomic operations on RoutingContextImplBase HOT 1
- Rx Version of OAuth2AuthHandler Handler fails to add scopes HOT 2
- Vertx web randomly returns 404 error for certain POST requests even though for other similar requests it returns 200 HOT 2
- ChainAuthHandlerImpl#postAuthentication throws NPE HOT 1
- BodyHandler should not be added before the ProxyHandler HOT 2
- after RoutingContext.reroute(), TimeoutHandler still occured HOT 1
- Request to add localstorage-functonalities HOT 1
- GraphQL: Combination of request batching and Automatic Persisted Queries fails HOT 1
- New web client expectation, result type differ from error type HOT 5
- Exeptionhandler not working correctly HOT 5
- HTTP 1.0 request causes "Unhandled exception in router" HOT 4
- Catch all error handler
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vertx-web.