I'm trying to track down a problem in our Java, SpringMVC/WebFlow web application, that seems to occur whenever some extra, unexpected requests arrive from Firefox, with no session cookie attached, and with some Sec-Fetch headers different from the requests before and after them:
Sec-Fetch-Dest=empty;Sec-Fetch-Mode=cors;Sec-Fetch-Site=same-origin
These requests do not appear in the Firefox developer panel's network tab, even with all requests selected.
But both the HTTP access log and a custom "log everything" filter show the above, with the same Firefox User Agent, no cookies, and no Referer header.
e.g.
9:13:12,426 DEBUG RequestLogFilter:GET->http://localhost:9080/payment/pos?execution=e1s1 (null/false), headers:Host=localhost:9080;User-Agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0;Accept=/;Accept-Language=en-US,en;q=0.8,es-MX;q=0.5,es;q=0.3;Accept-Encoding=gzip, deflate, br;DNT=1;Connection=keep-alive;Sec-Fetch-Dest=empty;Sec-Fetch-Mode=cors;Sec-Fetch-Site=same-origin;, cookies:
(Where "null/false" is the HttpServletRequest.getRequestedSessionId and isRequestedSessionIdValid().)
I can run the same sequence of web requests dozens or more times without seeing these extra requests appear, it's quite unpredictable. With or without fresh/private/incognito, cleared cookies, etc.
I'm looking for any ideas why Firefox is sending these requests. And, no, I don't think this is specific to Firefox. We've seen log evidence that Chrome at least seems be doing something similar in our production environment, but I haven't yet been able to duplicate it under Chrome (107) locally, where I have all this additional logging enabled.
Related
Users have started having problems with Flash-based traffic under Chrome 80: Cookies are not being sent with POST requests.
I'm aware of the SameSite updates, but our traffic is all same-domain, so I assumed this wouldn't affect us.
Debugging the request headers from the debug tools:
Here's what I note:
In an older version of Chrome 73:
there are no Sec-Fetch-* headers
Origin header is always correct
cookies are sent properly
In Chrome 80, GET requests:
Origin is correct, and cookies are sent
now has Sec-Fetch-* headers
the Sec-Fetch-Site cookie says cross-site -- Is this right? This is determined by the browser, correct? Why would Chrome label the traffic as cross-site? - the request URL is the same as my page, same as window.location.hostname.
In Chrome 80, POST requests:
Sec-Fetch-* cookies same as GET
the Origin header is null - wait, why? This also is assigned by the browser, right? Why null?
cookies are not sent
This makes absolutely no sense to me. It's always worked, and we don't use multiple domains, and our cookies are secure and httponly. Can someone help me understand:
why Chrome 80 would label my requests as Sec-Fetch-Site: cross-site?
why Chrome 80 would send Origin: null and no cookies for POSTs?
I am experiencing the same problem. For the post request from Flash, sometimes the request doesn't contain cookies at all, sometimes it only contains one cookie key (I have multiple keys in my cookie). It looks like a bug in Chrome 80, unless they did it on purpose b/c they want to kill Flash for a long time.
So I have the same website making the same request to the same server on (1) Chrome 76 and (2) Chrome 77 from different networks and computers.
One request has (1) Sec-Fetch-Mode: no-cors, Sec-Fetch-Site: cross-site and the other one (2) Sec-Fetch-Mode: cors, Sec-Fetch-Site: same-site.
The one with no-cors fails with a 400 to a C# Web API endpoint with CORS enabled (for years and thousands of different users on all kinds of devices).
What is going on? There is talk of a Chrome bug not sending that header for pre-flight, but there it is and set to no-cors.
Security setting or bug in Chrome? Fixable server-side or front-end-side?
This is sent by an XMLHttpRequest, not the new Fetch-API.
POST/PUT request to append a new row using Google Spreadsheet API returns 404 error.
Here is the API reference doc for append method in Google Spreadsheet API https://developers.google.com/sheets/api/reference/rest/v4/spreadsheets.values/append
Below is the request & response. If the ':append' in the url path is removed, then the request works fine. But the new data overrides the existing row. Any idea what's wrong with this append request to add a new rows in the sheet
Request URL:https://sheets.googleapis.com/v4/spreadsheets/1gpa0ByqgiDbGawyStfsJit8SdJfgi0rQsAAlzWkU7uM/values/**A2:append**?valueInputOption=RAW&alt=json
Request Method:PUT
Status Code:**404**
Response Headers
status:404
Request Headers
Provisional headers are shown
Authorization:Bearer xxxxxxx
Content-Type:application/json
Origin:chrome-extension://xxxxxxx
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
Request Payload
view source
{values: []}
values:[]
Follow this tutorial on how to insert data to a google spreadsheet via POST or GET. You may also try the workaround given in this link.
Clear the cache and cookies.
Try an incognito or private window.
Try another browser or operating system. (Here is a list of supported configurations.)
Disable browser plugins or extensions. (Chrome, Firefox, Internet Explorer, and Safari instructions.)
Hope this helps.
I was working on chrome extension with motive of intercepting all HTTP(S) requests/responses and log all headers into persistent file (on disk). I was almost close to my goal. But when I looked some requests closely, I found that in many requests "If-None-Match" and "If-Modified-Since" are missing in requestHeaders. Though, I can see them in Network panel displayed by the Developer Tools.
I tried hard to figure out any patterns, causing such behavior. But, unfortunately there is no such pattern.
Anybody please help.
The receive the list of requestHeader is necessary to use the onBeforeSendHeaders event from chrome.webRequest API.
In the onBeforeSendHeaders description is mentioned that some headers are not available for reading/processing:
Authorization
Cache-Control
Connection
Content-Length
Host
If-Modified-Since
If-None-Match
If-Range
Partial-Data
Pragma
Proxy-Authorization
Proxy-Connection
Transfer-Encoding
I'm afraid you will not be able to read or modify these headers, because it's an API forced limitation.
In DevTools on the Timing tab you can see the following states:
_
Except 'Queueing' all states are explained in the DevTools documentation. Do you know what browser does in the Queueing phase ? What queue are we talking about ?
Thx
Additionally it seems that Queueing can take place at the beginning of connection setup and also at the beginning of the 'Request/Response' phase ?
From: Chrome Developers - Network features reference
Queuing
If a request is queued it indicated that:
The request was postponed by the rendering engine because it's considered lower priority than critical resources (such as scripts/styles). This often happens with images.
The request was put on hold to wait for an unavailable TCP socket that's about to free up.
The request was put on hold because the browser only allows six TCP connections per origin on HTTP 1.
Time spent making disk cache entries (typically very quick.)
Update from #cyptus comment:
With chrome v76 the network tabs will hide the CORS preflight (OPTIONS) request. The request that triggered this CORS will include the time the (invisible) OPTIONS request took in the queueing timing.
Update from #tamilsweet comment:
To show the CORS preflight follow Chrome not showing OPTIONS requests in Network tab
Another possibility may be there is a fresh service worker which is trying to install or activate. Keep the service worker url solid among your page visits.