Avatar for Username

Zoeken in Support

Vermijd ondersteuningsscams. We zullen u nooit vragen een telefoonnummer te bellen, er een sms naar te sturen of persoonlijke gegevens te delen. Meld verdachte activiteit met de optie ‘Misbruik melden’.

Meer info

Deze conversatie is gearchiveerd. Stel een nieuwe vraag als u hulp nodig hebt.

Firefox does not send If-None-Match header for resources which had an etag in the previous response

  • 2 antwoorden
  • 2 hebben dit probleem
  • 1 weergave
  • Laatste antwoord van schlm3

schlm3
schlm3
more options

We have webservices which send json data to our webapp. The response headers have ETag-header and Chrome and IE11 correctly use that header (they send the etag in the if-none-match header of the next request). FF however ignores the etag and does not send it with the next request. I have already checked, that the cach in devtools is not deactivated. Thats how my response headers look like:

HTTP/1.1 200 Cache-Control: private X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Set-Cookie: JSESSIONID=0457E5621AE57A9F20350027834D7619; Path=/w3-dev; Secure; HttpOnly ETag: W/"bbb4975d-c81b" Vary: Accept-Encoding Content-Encoding: gzip Content-Type: application/json Content-Length: 1739 Date: Fri, 12 Apr 2019 19:52:46 GMT Server: -

And this is the requestheader from FF for the next request:

Host: bdna03:8443 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0 Accept: application/json Accept-Language: de-CH,de;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate, br Referer: https://bdna03:8443/w3-dev/src/demo/index.html Connection: keep-alive Cookie: UID=XYdOZcb....

We have webservices which send json data to our webapp. The response headers have ETag-header and Chrome and IE11 correctly use that header (they send the etag in the if-none-match header of the next request). FF however ignores the etag and does not send it with the next request. I have already checked, that the cach in devtools is not deactivated. Thats how my response headers look like: HTTP/1.1 200 Cache-Control: private X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Set-Cookie: JSESSIONID=0457E5621AE57A9F20350027834D7619; Path=/w3-dev; Secure; HttpOnly ETag: W/"bbb4975d-c81b" Vary: Accept-Encoding Content-Encoding: gzip Content-Type: application/json Content-Length: 1739 Date: Fri, 12 Apr 2019 19:52:46 GMT Server: - And this is the requestheader from FF for the next request: Host: bdna03:8443 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0 Accept: application/json Accept-Language: de-CH,de;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate, br Referer: https://bdna03:8443/w3-dev/src/demo/index.html Connection: keep-alive Cookie: UID=XYdOZcb....

Alle antwoorden (2)

schlm3
schlm3 Vraageigenaar
more options

A thing which is strange is, that when I try to clean my local cache, it reports, that the cache has "0 Bytes". Seems that FF is not using a cache at all.

schlm3
schlm3 Vraageigenaar
more options

I have now uninstalled FF and reinstalled it. Agreed to "start from scratch". This fixed the caching-problem.

But now, I have another problem. We use an internal CA-Certificate for our internal server TLS-Certificates. This was no problem with the former installation. I was easily able to import that CA into the Certificate store. But with the fresh installed FF 66.0.3, when ever I try to import the CA-Certificate, nothing happens. The Cert-Info Icon remains with an amber warning...