I'm trying to send a request with a session cookie, but when the request is sent the value for that cookie changes.
Here is how the cookie looks:
Here is how it looks after the request has been sent:
What is happening ?
Sorry for the late answer to this question. The only reason I see for the cookie to change is if the server sends back a Set-Cookie header in the response.
Paw will behave like web browsers by sending by default a Cookie header with the cookies stored for this domain, and will store new cookies when the server sends back a Set-Cookie header.
You can see all cookies stored in Paw by going to the left panel > Sessions > Manage:
Also, please note that you have the ability to disable cookie sending and/or cookie saving for each request in the Request > Options tab:
Related
In the Set-Cookie docs, it is mentioned:
The Set-Cookie HTTP response header is used to send a cookie from the
server to the user agent, so that the user agent can send it back to
the server later.
Is there somthing equal for telling the user-agent (browser) to send some headers in later request? something like Set-Header maybe.
Ive made some configurations to (finally) have my cookies set on HTTP only.
"Seem" to work.
Ive tried them with postman and I have the following:
When I hit the login page:
On the cookies section, my cookie with name JSESSIONID appears to be HTTP only (it has the check)
When I enter to the logged area , the same result...
The headers dont give me more details.
Then,
I check it with google chrome. I open the developers toolbar.
I load the login page.
At the headers on the response headers I get
Set-Cookie: JSESSIONID=434434..... HttpOnly
So, its fine (I guess).
Then I reload the page (or sign in).
Then the problem:
No response headers received.
The Request Headers brings my cookie (with the same ID at then the previous one) without the httponly, host info or any other cookie value I set before.
At the cookies tab I get Request Cookies only and no Response cookie.
And the request cookie is non http-only
At my resources tab, the Cookie is there, as HTTP only and with the previous values I set.
My question now is... Is it a really http-only cookie? Or my configuration is not properly set?
Should I always get the response cookie or the request cookie should be always http-only (In case I am trying to set it as http-only) or is this behavior normal (or at least accepted) ?
When I try to print my cookie with Javascript at both scenarios I get a null as response (what makes me think then it is correct).
Ideas?
Client doesn't send cookie attributes other than name and value back to server.
See also RFC6265 section 4.2.2 (emphasis mine).
4.2.2. Semantics
Each cookie-pair represents a cookie stored by the user agent. The
cookie-pair contains the cookie-name and cookie-value the user agent
received in the Set-Cookie header.
Notice that the cookie attributes are not returned. In particular,
the server cannot determine from the Cookie header alone when a
cookie will expire, for which hosts the cookie is valid, for which
paths the cookie is valid, or whether the cookie was set with the
Secure or HttpOnly attributes.
Everything's behaving as specified.
Does the browser set a cookie after it receives the header or after it receives the body? This is relevant when sending a large file in the body of the request.
I would think a browser would set the cookie as it is processing the response headers, since the cookie information is in there. It doesn't make much sense to receive the headers, then set the cookies after it processes the html.
When you set a cookie, you set the raw cookie data, and some metadata. This metadata includes the path for where the cookie is valid, the expiration time of the cookie, and so on.
When a browser performs a request, what exactly will the browsers send with it? Will it send the full cookie, with all the "metadata"? Or only the actual data of the cookie, without the metadata?
No only the value of the cookie is returned in subsequent requests, the other metadata stays on the client.
When you define a cookie on the server a Set-Cookie header is created in the response carrying the name, value and other metadata about the cookie. Multiple Cookies will create multiple Set-Cookie headers in the response.
When the browser makes subsequent requests it checks its "database" of available cookies to see which cookies are appropriate for the path being requested. It then creates a single Cookie header in the request that carries just a series of name/value pairs of the qualifying cookies.
Its important to keep tight control on the number of cookies and the size of the data otherwise you may find that the weight of cookie data being sent for each and every request can be deterimental to performance. This would be much worse if the metadata were returned with the cookies as well.
The server sets the cookie with the "Set-Cookie" header. This contains the metadata (path and expiry), if specified. The client (browser) only sends the cookie itself in a "Cookie" header.
Firebug is a useful tool for Firefox to view all these headers. Similar tools should be available for other browsers.
only the cookie data is sent to server,other metadata is for the browser to perform some actions like cookie expiration
the user-agent will re-transmit the path, domain, and port attributes if the cookie was set under RFC2965 (via the Set-Cookie2 header) and if the attribute was specified by the server. a sample request might contain:
Cookie: $Version="1";
name="val"; $Path="/site"; $Domain=".example.com"; $Port="81";
name="val"; $Path="/site/dir"; $Domain=".example.com"; $Port="81"
if the cookie was specified using the original netscape Set-Cookie header, no attributes will be re-transmitted. if multiple cookies with the same name (but different paths) are valid for the request, all matching cookies will be supplied. an example request:
Cookie: name=val; name=val2
the full spec is here:
https://www.rfc-editor.org/rfc/rfc2965
the original netscape spec is here:
http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsref/std/cookie_spec.html
Since HTTP is a stateless protocol, when a client makes a number of requests to the server, how does the server uniquely identify a particular client's requests over a period of time say t1, t2, t3..
I browsed the web and came across terms like session id, URL rewriting and cookies. But it would be great if someone explains it in a better way. Specifically which part of the HTTP request and response would be used for session tracking?
As you mentioned, common ways to implement HTTP session tracking include URL rewriting and cookies. Session tracking basically requires that a session ID is maintained across multiple requests to the server. This means that each time a given client makes a request to the server, it passes the same session ID. The server can use this ID to lookup the session information it maintains.
When using cookies, the server asks the client to store a cookie by setting the Set-Cookie HTTP response header. This cookie contains the unique session ID assigned to that client - in this example the string 'ABAD1D':
Set-Cookie: JSESSIONID=ABAD1D;path=/
The cookie is then sent back to the server by the client using the Cookie HTTP request header on each request and thus the server is informed on each request the session ID currently assigned to the client.
Cookie: JSESSIONID=ABAD1D
When using URL rewriting, this same session ID is instead sent somewhere in the URL. Again, the server extracts the session ID from the URL so that it can lookup the session for a particular client:
http://my.app.com/index.jsp;JSESSIONID=ABAD1D
However, the server must also make sure that any URLs in the web pages sent back to the client are also rewritten to contain that particular clients session ID. As the session ID is encoded in the URLs, this method of session tracking is transparent to the browser. Often a server will resort to URL rewriting if it finds it is unable to set a session cookie on the client - implying that the client does not support/allow cookies.
Note that sessions can expire. This means that if the server does not 'see' a given session ID for a period of time, it may remove the session data to preserve resources.
Specifically which part of the HTTP
request and response would be used for
session tracking?
In the HTTP response, the server can set a cookie. It does so with the Set-Cookie header. For example:
Set-Cookie: session=12345; path=/
The client then returns the value of all cookies that match the properties that were set along with the cookie, which can include path (as above) and domain, and that haven't expired yet.
The cookie is sent back to the server as part of the HTTP headers. For example:
Cookie: session=12345
None of the original property information is sent back with the cookie.
A unique cookie allows the server to associate a unique key with a particular browser instance. The server can then use that key as an index into a hash table or a database table that holds unique per-user state information.
Session tracking is a server side thing.
A web server issues some session identifier that is returned to the browser. Browser submits this session identifier along with each request.
This is probably done using cookies transparently for the user.
the session handling is in most case handled by sending a cookie to the client. that cookie would be sent back to the server on every request from that particular client.
The session id will be associated with some resources on server side (file,ram space) so the server by reading the session id in the cookie can find this resource and then know which client it was.
Find enough details here
HTTP Sessions are the recommended approach. A session identifies the requests that originate from the same browser during the period of conversation. All the servlets can share the same session. The JSESSIONID is generated by the server and can be passed to client through cookies, URL re-writing (if cookies are turned off) or built-in SSL mechanism. Care should be taken to minimize size of objects stored in session and objects stored in session should be serializable. In a Java servlet the session can be obtained as follows:
HttpSession session = request.getSession(); //returns current session or a new session
Sessions can be timed out (configured in web.xml) or manually invalidated.
HTTP Session allows web servers to maintain user identity and store user specific data during multiple request/response between client and we application