Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add Etag support in HTTP::StaticFileHandler #6145
I was trying to extract some logic in Kemal - kemalcr/kemal#440 - it seems at this point static file handler is kinda hard to re-use as it's quite coupled - a lot of stuff is going on there at the moment.
Maybe injecting conditional into handle arguments might be a good idea? So you can basically plug-in anything you want there (you could also remove caching by injecting some class that will simply return false for
It's just a totally random proposal / proof of concept (wip) - please let me know what you think about it so we can proceed with it / change the approach or simply reject it
Keep up great work, I'm really enjoying having 'ruby experience' in a compiled language - it's truly awesome
It's certainly a good idea to clean up and reorder some of the logic in that class. But I don't see the point in having a
It's particularly odd that this PR adds support for
In my opinion,
Thanks for quick feedback! We can pack logic internally and still keep it extendable - I thought why not making it more configurable out of the box.
As for using both simultaneously - I will give it another go; by (quickly :x) looking at rfc7232 before submitting that proposal I thought it made no sense because of:
But I guess we still have to deal with some older clients and support both at the same time on server side
Will ping you hopefully this week for further discussion and I'm still hoping for more feedback ;).
This looks really good overall
A few notes regarding general design:
- I don't see a benefit from isolating the behaviour in an additional
Cachetype. These methods should just be (private) instance methods in
StaticFileHandler. They're of no use outside of that class.
- Combining methods
match?would avoid lot's of boiler plate and would even make it better understandable what's going on. IMHO it doesn't make sense to separate these methods.
Support for a list of etags in
If-None-Match header and validating each of them would be great, but that can be added when the general design is settled (should be fairly easy).
Thanks for comments guys!
@straight-shoota I tried to keep it in a single file/class as suggested - but damn it seemed cluttered - I will give it another go tho and let's decide one more important issues are addressed ;-)
Yes, I mean
We could certainly generalize
Currently, these methods are only internal implementation and as such, don't need isolated unit tests at all.
add Etag headershould also test the etag is different when mtime changes.
- Would you rewrite the other existing examples to use
initial_responseas well? Name suggestions:
returns 304 Not Modified for younger than Last-Modifiedand
serves content for older than Last-Modified. You can use
HTTP.parse_timeto parse the
Last-Modifiedheader for calculations.
Just a small improvement, apart from that: