-
-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support If-Match and If-Unmodified-Since #130
Comments
Besides just adding a kitchen sink of supporting every optional thing, I have a question as to what benefit it adds over the current 304 Not Modified. I ask because, as it even suggests in the specs, that those precondition checks are only really useful for state-modifying methods, which this modules doesn't support anyway, so just wanted to get your thoughts on what use-cases you have in mind. |
I'm not sure what you're referring to when you reference the "current 304 Not Modified." I assume you're referring to this bit: // conditional GET support
if (this.isConditionalGET() && this.isCachable() && this.isFresh()) {
this.notModified()
return
} The above will not respect clients that send requests with the
Both headers are useful for "resumable" downloads. Both sections linked say the following (where "safe methods" are
|
That's correct, because those are supposed to send 412, not 304 :)
Ah, I see, didn't know that. Of course, I'm not sure of the usefulness since |
Very true, but a developer might set the |
This feature is causing a lot of issue reports. I am inclined to pull the feature back out. |
Maybe limit it to only GET/HEAD requests? It's up to you. |
Are these issues being posted somewhere else? |
Because this is a dependency of Express, it's been in the Express IRC channel, the Express Gitter, one on the Express issue tracker, and another on the serve-static issue tracker (which also depends on this), and that's only the ones I know of. It has only been a few days since this got added to Express. As far as I can tell, they are doing GET/HEAD requests, so not sure on how that would change anything. |
Ah, is it just the |
That is the only confirmed cause yet, I'm still waiting to hear back from everyone. I also though that, but that wouldn't help with |
Commit efdb43a is the solution that I think would help work-around the issue. |
That looks good to me! |
I think you could also just cast the "parsed" date to a number |
Well, |
Ah, good point. |
haha. Yea, that commit was the "least bad" fix I could think of that both (a) worked and (b) didn't add an untestable branch without forcing me to override |
Wow, that datejs module doesn't even return a number for |
Hm.... Well, then... |
I believe this is the implementation: https://github.com/abritinthebay/datejs/blob/45293f998892b938da792f5b062eb1c656e696ca/src/core/parser.js#L131-L155 |
The open issue in datejs: abritinthebay/datejs#263 |
I'm still thinking on it, but I feel inclined to just at least degrade to just having the features be unsupported for this weird behavior, which I think the previous commit accomplishes. As in, if datejs is used, since |
Yeah, I'm surprised datejs hasn't caused more issues when used with express. I think your commit is a good compromise though. It should resolve the immediate issue. |
👍 feel free to PR anything if you think of something later, though :) Just releasing to make some people's pain go away from the upgrade, haha. |
If-Match
The server will send back the requested resource only if it matches one of the listed
ETags
otherwise the response will be a412
(Precondition Failed) error.If-Unmodified-Since
The server will send back the requested resource only if it has not been last modified after the given date. If the request has been modified after the given date, the response will be a
412
(Precondition Failed) error.The text was updated successfully, but these errors were encountered: