On 22/08/2024 14:29, Jiřička, Martin wrote:
Hi,
I was investigating an issue with our single-page app that is using
Tomcat on server side. The app sometimes did not load in browser. It
turned out Chrome can requests client application bundle with header
like this:
If-None-Match: W/"101052-1724152266000"-gzip
Default servlet rejects such request with HTTP Status 400 – Bad Request.
To test it I installed Tomcat 9.0.93 and queried default ROOT application:
$ curl -sw '%{http_code}\n' --output /dev/null -H 'If-None-Match:
W/"101052-1724152266000"-gzip' localhost:8080/tomcat.css
400
Problematic part is "-gzip", without it it works:
$ curl -sw '%{http_code}\n' --output /dev/null -H 'If-None-Match:
W/"101052-1724152266000"' localhost:8080/tomcat.css
200
I have no idea whether the header is RFC-valid or not,
It isn't. From RFC 9110:
13.1.2
If-None-Match = "*" / #entity-tag
8.8.3
entity-tag = [ weak ] opaque-tag
weak = %s"W/"
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text
The -gzip should be inside the double quotes.
but since it is
used by major browser/s and status 400 can break things, is there some
option how to silently ignore invalid(?) If-None-Match?
Sorry, no.
It might be worth tracking down what is generating the invalid ETag. It
is possible that the browser is just echoing back an invalid ETag it
originally received.
Whether the browser should accept and/or echo an invalid ETag is
arguable. I suspect it does so for interoperability reasons.
I've done a quick check of the Tomcat source and I don't think it is
Tomcat that is generating that ETag.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
