Hacker News Reader

Comment by mananaysiempre | Hacker News Reader

Whether it should or not depends on whether you understand a 403 as a refusal to let you do the given method against the given resource at all, or as a refusal to do this one specific request. The HTTP spec (as I’ve just learned) does support the narrower interpretation if the server wishes it: the description for 403 is just that “[t]he server understood the request, but is refusing to fulfill it”, with no implications regarding other requests for this resource.

View on HN

Again, it's a range request though. What if the browser simply didn't send a network request at all and just synchronously returned the partial result from the cache. You agree that would be correct (if arguably not very useful), right? The point is that the 403 isn't required to be seen, at all. You can't require the browser return a value that the browser doesn't know about.

It's a cache consistency bug at its root. The value was there, and now it's not. The reporter says "the browser is responsible for cache coherency" (call this the "MESI camp"). The Chrome folks say "the app is responsible for cache coherency" (the "unsnooped incoherent" gang). Neither is wrong. And the problem remains obscure regardless.

I'm the author of the post.

I'm not sure Chrome's current caching behavior is helpful because the second response does not indicate which part of the data is returned. So, the application has no choice but to discard the data.

But thank you for your comments. This helped me to crystalize why I think this is a bug.

Yeah, if there's no way to tell from the request which range has actually been returned that seems like a deal-breaker. The spec’s allowance for a partial response is explicitly motivated by the response being self-describing, and if after Chrome’s creative reinterpretation it is not, then it’s not clear what the client could even do.

There's no clear way to define "correct" in this case regardless. The whole premise behind a range request is that the data is immutable (because otherwise it wouldn't make sense to be able to fetch it piecewise), and it's mutating here by disappearing! What are you supposed to do, really? The answer is always going to be app-dependent, the browser can't get it right because the server is being obtuse and confusing.

When we handle this in the hardware world it's via algorithms that know about the mutability of the cached data and operate on top of primitives like "flush" and "invalidate" that can restore the inconsistent memory system to a known state. HTTP didn't spec that stuff, but the closest analog is "fetch it again", which is exactly what the suggested workaround is in the bug.

Reply on news.ycombinator.com