Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ETag and HTTP Caching

rednafi.com

Post reply on HN
Print view View original

51–60 of 92 posts

Re: ETag and HTTP Caching

#51

Post by johneth »

joosters wrote: post #43

I've not seen a very convincing use-case for ETags vs Last-Modified date caching. In the example request, the server still has to do all of the work generating the page, in order to calculate the ETag and then determine whether or not the page has changed. In most situations, it's simpler to have timestamps to compare against, because that gives the server a faster way to spot unmodified data. e.g. you get a HTTP req…

When I use ETags, I'll generate the ETag value once (on startup), then cache and serve that value. When the resource changes, regenerate the ETag value.

Obviously doesn't work if you're using ETags on dynamic resources, but works well for non-dynamic, but unpredictably frequently changing resources.

Re: ETag and HTTP Caching

#52

Post by rednafi »

nikolayasdf123 wrote: post #45

if only browsers respected this. none of browsers use ETag and If-None-Match mechanism. instead they do their own wizzardy caching...

Hmm... Chrome seems to handle this quite well, at least in my experience. I'm curious about what sort of issue you encountered.

Re: ETag and HTTP Caching

#53

Post by rednafi »

rollulus wrote: post #35

I recently implemented this, great write-up. Regarding the hashing function, I’m curious about opinions. In my implementation I went for a cheap but weak cryptographic hash at first. Then I got worried that some auditor would flag it and time would be wasted convincing them to change their mind. But then I stumbled upon FNV [1], a non-cryptographic hash and part of Go’s standard library and went for it. Any thoughts?…

I feel like people tend to overthink in this regard. If SHA-256 hashing is good enough for GitHub's REST endpoints, it's good enough for me.

If you're implementing weak validation, then you might need to preprocess the payload before running it through the hash function. For example, if your payload is JSON and you want to make it format-agnostic, then you'll need to normalize the payload and then compute the hash.

In either case, the hashing algo probably doesn't matter as much.

Re: ETag and HTTP Caching

#54

Post by troupo »

esafak wrote: post #26
alganet wrote: post #25

This is nice. It reminds of how miserable my life is. — Which HTTP code I should return for my API? I already used 404, 403, but I need another one. Damn, HTTP is so old and it makes no sense. — You can't use HTTP codes like that Bob, they're not a free choice. They're for the protocol, not for your app. — Let's look at the list. Hm... "412 Precondition Failed". Hey, it sounds nice. It fits to my use case. I'm gonna…

Which article would you ask Bob to read to learn the right way to do it?

HTTP decision diagram: https://github.com/for-GET/http-decision-diagram and Know Your HTTP Well: https://github.com/for-GET/know-your-http-well

Re: ETag and HTTP Caching

#55

Post by rednafi »

vbezhenar wrote: post #49
alganet wrote: post #25

This is nice. It reminds of how miserable my life is. — Which HTTP code I should return for my API? I already used 404, 403, but I need another one. Damn, HTTP is so old and it makes no sense. — You can't use HTTP codes like that Bob, they're not a free choice. They're for the protocol, not for your app. — Let's look at the list. Hm... "412 Precondition Failed". Hey, it sounds nice. It fits to my use case. I'm gonna…

I'm using 400 for everything, to the hell with it.

Yeah, same. Otherwise, domain and protocol error codes become a confusing mess.

Re: ETag and HTTP Caching

#56

Post by HdS84 »

alganet wrote: post #25

This is nice. It reminds of how miserable my life is. — Which HTTP code I should return for my API? I already used 404, 403, but I need another one. Damn, HTTP is so old and it makes no sense. — You can't use HTTP codes like that Bob, they're not a free choice. They're for the protocol, not for your app. — Let's look at the list. Hm... "412 Precondition Failed". Hey, it sounds nice. It fits to my use case. I'm gonna…

The problem ist that there are multiple status codes which should be used (400, 422, 500 etc). But others are massive footguns. Would have been better to have a "technical" status code and a "application status code", but hey that would have required better engineering.

Re: ETag and HTTP Caching

#57

Post by HdS84 »

alganet wrote: post #48
quectophoton wrote: post #40

Earlier quoted context omitted.

To be fair, to me HTTP looks like: - The first line of an HTTP request has its own format (space-separated-ish), and mixes method and URL path. - The URL path in that first line has its own format and weird escaping, and mixes one path with zero-or-more key value pairs. - The headers have their own format. - The body has its own format. Most (all?) HTTP libraries for clients and servers abstract all that mess away in…

URLs are opaque: - https://www.w3.org/2000/12/drm-ws/pp/connolly/slide8-0.html - https://www.w3.org/DesignIssues/Axioms.html#opaque For the protocol, any structure or meaning in URLs is irrelevant. It is one more example of mixing application domain with protocol level stuff. HTTP header format goes back to ARPA times. Email reused them, so did HTTP. - https://datatracker.ietf.org/doc/html/rfc822#section-3.2 Many of…

I would love if we could improve on HTTP - even just clearly separating protocol from application would be so great. Maybe dropping some cruft, like the accept headers and so on. But yes, doing that is total folly.

Re: ETag and HTTP Caching

#58

Post by quectophoton »

alganet wrote: post #48
quectophoton wrote: post #40

Earlier quoted context omitted.

To be fair, to me HTTP looks like: - The first line of an HTTP request has its own format (space-separated-ish), and mixes method and URL path. - The URL path in that first line has its own format and weird escaping, and mixes one path with zero-or-more key value pairs. - The headers have their own format. - The body has its own format. Most (all?) HTTP libraries for clients and servers abstract all that mess away in…

URLs are opaque: - https://www.w3.org/2000/12/drm-ws/pp/connolly/slide8-0.html - https://www.w3.org/DesignIssues/Axioms.html#opaque For the protocol, any structure or meaning in URLs is irrelevant. It is one more example of mixing application domain with protocol level stuff. HTTP header format goes back to ARPA times. Email reused them, so did HTTP. - https://datatracker.ietf.org/doc/html/rfc822#section-3.2 Many of…

Ah yeah no disagreements there. Better something that already works and is widely used with good ecosystem around it, than risk an xkcd 927 situation.

I understand that the people at the time (presumably) did it the best they could with the information and knowledge they had at the moment, while keeping backwards compatibility.

I only know a bit about HTTP/0.9 and can see how we moved from that to what we have today. I just find the current situation sad.

Like when something only supports ASCII, or only supports IPv4, or assumes I only have 1 CPU thread. Or like when some binary file is encoded in base64 before being sent over the network, only to be decoded on the receiving end. Stuff like that.

But I only feel that way thanks to having the huge benefit of hindsight and modern technology.

Re: ETag and HTTP Caching

#59

Post by alganet »

HdS84 wrote: post #57
alganet wrote: post #48

Earlier quoted context omitted.

URLs are opaque: - https://www.w3.org/2000/12/drm-ws/pp/connolly/slide8-0.html - https://www.w3.org/DesignIssues/Axioms.html#opaque For the protocol, any structure or meaning in URLs is irrelevant. It is one more example of mixing application domain with protocol level stuff. HTTP header format goes back to ARPA times. Email reused them, so did HTTP. - https://datatracker.ietf.org/doc/html/rfc822#section-3.2 Many of…

I would love if we could improve on HTTP - even just clearly separating protocol from application would be so great. Maybe dropping some cruft, like the accept headers and so on. But yes, doing that is total folly.

The separation is your choice. It is not enforced, as this would require limitations that are not worth having.

You can totally drop accept headers if you write your own client and server implementation. HTTP works fine without them. The web as a living organism, not so much.

But hey, we don't need content type negotiation, right? XML will reign forever, mp3 is the ultimate audio format. It's not like new codecs and document types appear all the time and some kind of underlying architecture has to reserve space for that kind of change.

Re: ETag and HTTP Caching

#60

Post by alganet »

quectophoton wrote: post #58
alganet wrote: post #48

Earlier quoted context omitted.

URLs are opaque: - https://www.w3.org/2000/12/drm-ws/pp/connolly/slide8-0.html - https://www.w3.org/DesignIssues/Axioms.html#opaque For the protocol, any structure or meaning in URLs is irrelevant. It is one more example of mixing application domain with protocol level stuff. HTTP header format goes back to ARPA times. Email reused them, so did HTTP. - https://datatracker.ietf.org/doc/html/rfc822#section-3.2 Many of…

Ah yeah no disagreements there. Better something that already works and is widely used with good ecosystem around it, than risk an xkcd 927 situation. I understand that the people at the time (presumably) did it the best they could with the information and knowledge they had at the moment, while keeping backwards compatibility. I only know a bit about HTTP/0.9 and can see how we moved from that to what we have today.…

If ASCII is obsolete compared to Unicode, IPv4 is obsolete compared to IPv6, and single threadness is obsolete compared to multi-threading (I don't think that is a valid comparison, but let's go with it), then which standard makes HTTP obsolete?

HTTP/3 was published in 2022.

Post reply on HN