receiving 304 not modified from heahdk.net
silverbucket opened this issue · 9 comments
Request URL:https://heahdk.net/storage/silverbucket/messages/accounts/xmpp/
Request Method:GET
Status Code:304 Not Modified
Request Headersview source
Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Authorization:Bearer 4d8ddece60ad4529b2c29ea0371bec71fa2b234c3597dd5
Connection:keep-alive
Host:heahdk.net
If-None-Match:"f3f6473b77b60f7c63a0f4abdd434fff"
Origin:http://local.dev:7000
Referer:http://local.dev:7000/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Response Headersview source
Access-Control-Allow-Headers:Origin, Authorization, Content-Type, ETag
Access-Control-Allow-Methods:GET, PUT, DELETE
Access-Control-Allow-Origin:http://local.dev:7000
Cache-Control:max-age=0, private, must-revalidate
Connection:keep-alive
Date:Fri, 19 Apr 2013 14:16:37 GMT
ETag:"f3f6473b77b60f7c63a0f4abdd434fff"
Server:nginx/0.7.67
Status:304 Not Modified
X-Runtime:0.006243
X-UA-Compatible:IE=Edge,chrome=1
This seems to be because you're sending a If-None-Match header - is your browser doing that? Since the ETag hasn't changed, it shouldn't pose a problem that you're seeing 304. Do you have any evidence to the contrary?
I was getting cached results that had since been deleted. And yeah, my
browser was sending that header.
Michiel (sitting next to me) is saying that no matter what the browser is
sending, the response should never 304. In the next version maybe?
On Fri, Apr 19, 2013 at 4:48 PM, Niklas Cathor notifications@github.comwrote:
This seems to be because you're sending a If-None-Match header - is your
browser doing that? Since the ETag hasn't changed, it shouldn't pose a
problem that you're seeing 304. Do you have any evidence to the contrary?—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-16657067
.
tagging @michielbdejong
i agree, the response should never be 304, no matter what the headers the browser adds in. in theory it shouldn't pose a problem, if both the browser and the server know what they're doing, but it just makes it harder to know what's going on when you're debugging with the network tab.
I haven't run into the problem again, if you let me know what kind of
information you might need I can try to be more helpful next time. Though I
must confess I don't know enough about the protocol and mostly just wrote
what michiel told me too :)
On Sat, Apr 20, 2013 at 5:44 PM, Michiel@unhosted
notifications@github.comwrote:
i agree, the response should never be 304, no matter what the headers the
browser adds in. in theory it shouldn't pose a problem, if both the browser
and the server know what they're doing, but it just makes it harder to know
what's going on when you're debugging with the network tab.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-16706036
.
@michielbdejong I don't think it's a good idea to circumvent browser caching, as long as it works. If you don't want to see cached results in the network tab you could deactivate caching in your browser.
I don't see how the 304 would change the way the library behaves, as:
- The server won't send 304 unless the content really hasn't changed
- The library will see the original (cached) response, so no difference there.
The only thing that's different is that the response body won't be transmitted more often than needed.
+1 for using empty 304s where appropriate. We do it for our app hosting already, but I don't think we're doing it for remoteStorage yet. If nobody has grave concerns, we'd also implement it soon.
yeah, but should the be based on Last-Modified or on ETags? Since the (new) spec already defines conditional PUTs and DELETEs, it would probably make sense if it also defined conditional GETs, and then we would probably want to dictate that it should reacts to ETags, yet not to Last-Modified. see also remotestorage/spec#2
for now it's ok though, i guess
The only thing that makes sense is If-None-Match anyway. Computer clocks suck, especially in sync scenarios.