Closed rgajrawala closed 4 months ago
Just discovered this as well! I'm looking for a workaround. Will comment again if I find one
It's possible this is being trigged by a change in browser behavior. I am finding If-Modified-Since: 0
in the request headers that trigger the error.
EDIT: Turns out that this has been a feature of our application for years—it's a cache buster—but we weren't passing these headers to tornado in the past.
I agree that it should not be returning a 500 in this case. I would suggest the proper response is to return False
if the headers do not parse properly. With that in mind, here is perhaps a better workaround:
class MyStaticFileHandler(tornado.web.StaticFileHandler):
def should_return_304(self):
try:
return super().should_return_304()
except Exception:
return False
Looks like @mcg1969 is correct, and invalid If-Modified-Since headers should be ignored instead of returning a 5xx or 4xx error. RFC 9110 section 13.1.3 says "A recipient MUST ignore the If-Modified-Since header field if the received field value is not a valid HTTP-date".
Just coming over here to share that link! Thanks @bdarnell
@bdarnell I made a PR to fix this since we're unable to inject our own StaticFileHandler
into the third-party library we're using. https://github.com/tornadoweb/tornado/pull/3412
Fixed in #3412.
Hello, recently our application underwent a security scan and I noticed our Tornado app was returning HTTP 500 for some requests:
Looks like
tornado.web.StaticFileHandler.should_return_304
is blindly parsing theIf-Modified-Since
header resulting in 500s. Ideally, invalid headers would return 400s.