Repository navigation
Ignore an If-Modified-Since that is not a date, instead of failing the request - #897
Conversation
`shelf_static` reads the header through `Request.ifModifiedSince`, which throws a `FormatException` on anything it cannot parse. The request then failed with a 500 and an error dump, over a header the client sent: the report has a browser sending `Thu,27 Aug 2026 20:33:22 GMT`, missing the space after the weekday, and `GET /main.css` answering with a stack trace instead of the file. RFC 9110 says a recipient must ignore an `If-Modified-Since` field value that is not a valid date, so it is dropped and the file is served as if it had not been sent. The development proxy that serves the generated styles and the framework's own static handler both go through it. Fixes schultek#876
|
as the author of original issue, i can say that everything works perfectly after specifying this branch in |
|
Thanks for checking, @diquoks. Good to know it holds up on the machine where it showed up. The other half of your report, |
Package Version ReportThe following packages have been updated: |
schultek
left a comment
There was a problem hiding this comment.
LGTM, and thanks @diquoks for confirming this works.
@diegolopezrm Just one nit: can you shorten the changelog entry to one or max two sentences, it doesn't need that much specific detail regarding the exact cause of the issue.
i'm aware of that, replied to you in the issue earlier:
|
…fied-since # Conflicts: # packages/jaspr/CHANGELOG.md
|
Rebased on main, the changelog was the only conflict. About the red
|
schultek
left a comment
There was a problem hiding this comment.
LGTM.
I will fix the dependency issue on main.
Description
Fixes #876, and it is not about
styles: standalonein the end — that mode is just what makes the request happen.The trace in the report lands in
shelf_static:shelf_staticreadsIf-Modified-SincethroughRequest.ifModifiedSince, which throws aFormatExceptionon anything it cannot parse. So a client sending a date without the space after the weekday takes the request down with a 500 and an error dump, andmain.cssnever arrives. That also explains the two shapes the reporter sees — right after a reload, and then now and then on a refresh or from another browser: it happens whenever that client has a cached copy and sends the header back.RFC 9110 §13.1.3 is explicit that a recipient must ignore an
If-Modified-Sincefield value that is not a valid date. So it is dropped and the file is served as if it had not been sent.Measured against the real
shelf_static, with the exact value from the report:GET /main.cssTwo places go through it:
jaspr_cli's development proxy, which is what serves the generated styles and what the report hits, and the framework's own static handler inserver_handler.dart, which has the same exposure for anything it serves out ofweb/.What it does not fix
The second half of the report —
main.cssbeing generated after the server reloads — is untouched. It is a sequencing question between the css generation step and the server reload, and worth its own issue if it still bites once the 500 is gone.Type of Change
Tests
packages/jaspr/test/server/conditional_headers_test.dart, three cases against a file handler that reads the header the wayshelf_staticdoes: the value from the report is dropped and the file is served, a valid value is passed through and parses to the right instant, and no header stays no header.dart test -p vmis green inpackages/jaspr(184) anddart test test/helpersinpackages/jaspr_cli(24).Fixes #876