if only browsers respected this. none of browsers use ETag and If-None-Match mechanism. instead they do their own wizzardy caching...
It works correctly. What do you mean?
ETag and HTTP Caching
61–70 of 92 posts
Re: ETag and HTTP Caching
#62Earlier quoted context omitted.
So in my case, I am not using SRI. But I am using the CID as the name in the path. Using the example file from your link, I would host it as something like https://mywebsite.example.com/ipfs/QmPK1s3pNYLi9ERiq3BDxKa4X... And this was enough for that particular browser I was using to recognize that this file can be attempted to be retrieved directly from IPFS
Yea but the gateway can be compromised, so that is insecure
Brave wrote in 2021 that they had plans to verify the CID. Not sure if they have added that or not yet.
But either way, I run Brave with a local IPFS gateway on my laptop. So I think when it said that it could retrieve those files via IPFS for me, it meant in my case that those files would be retrieved from actual IPFS and not via a public IPFS gateway hosted on the web
Re: ETag and HTTP Caching
#63This 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’d just send Bob a link to https://http.cat/412 and hope they get too distracted to continue the conversation.
Re: ETag and HTTP Caching
#64The ETag can be _anything_. I have an API that serves "files" from a backend storage system. Whenever files are written a revision number is incremented. This is perfect for a weak validator and so my ETags are also blisfully short and semantically useful, typically: ETag: W/"750" This also means the API can just check the revision number and avoid pulling out and decompressing some of the larger payloads that are st…
A great standard but also provides an effective cookie-less mechanism for user tracking e.g. https://levelup.gitconnected.com/no-cookies-no-problem-using...
That's why tracking requires consent, regardless of the specific hack used to do it.
Re: ETag and HTTP Caching
#65Earlier quoted context omitted.
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…
Don't people use ?format=json or /foobar.json anyway?
Re: ETag and HTTP Caching
#66Earlier quoted context omitted.
My coworkers insisted on always returning 200 and having the status code in JSON. At least at that point it’s clearly not HTTP anymore, and it’s better than pretending to be compliant like your Bob. But something dies inside me whenever I have to work with it.
That's exactly what SOAP and GraphQL do, they always return 200
Isn’t SOAP theoretically “transport agnostic”. It doesn’t leverage http verbs either.
Re: ETag and HTTP Caching
#67I'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…
They are essentially the same thing. Sometimes you have a last modified timestamp handy and sometimes you have a revision number handy.
I would agree that you shouldn't be doing signifiant calculations -- like checksumming the contents of a file -- to determine the current etag value.
Also, the excessive semantics of timestamps is a negative. It adds complication which sometimes trips developers up but doesn't improve the caching.
Re: ETag and HTTP Caching
#68Earlier quoted context omitted.
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…
Don't people use ?format=json or /foobar.json anyway?
As I said, if you're writing your own client and server, you don't need Accept. You probably use just one homogenized content type.
Using `?format=json` is not offensive. It won't mess up some cache layer like improper status code semantics, so I don't really care that much about these if I see it. I wouldn't block a PR on that.
The overall web on the other hand, is supposed to be made of many different client and server implementations. Your browser still relies on Accept headers for displaying images, detecting language, uncompress gzipped responses, resuming paused downloads, showing that JSON API in a nice UI when you open in a dedicated tab, so many things.
To me, it makes sense to leverage the same content negotiation ideas for home grown stuff, even if only one content type is being used.
It starts being a problem if you're working on microservices, and one of them uses `.json` while other uses `?format=json`, made by different teams. The standard is the obvious solution. Instead, they'll either create inefficient clients full of complexities or fight until one of the workarounds prevail. So much easier to follow the standard.
Re: ETag and HTTP Caching
#69Re: ETag and HTTP Caching
#70This 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…
My coworkers insisted on always returning 200 and having the status code in JSON. At least at that point it’s clearly not HTTP anymore, and it’s better than pretending to be compliant like your Bob. But something dies inside me whenever I have to work with it.
I've taken a very operational view of HTTP errors, which is "What do I want things receiving this error to do?" Unfortunately, that's not a clean question since there's no list you can simple consult to get all behaviors that all HTTP error messages cause. The most important of these is, if this is being accessed by a browser, what will the error code make it do?
Fortunately, for a lot of my API-type work, I also get to not care. I don't want some smart cache to think it knows how to cache my responses or anything and don't care about the sort of infrastructure that thinks it understands HTTP doing anything with my request.
200 {"error": "..."} is not necessarily invalid from this point of view, either. 200, the request was successfully processed and the successful result of that request as far as HTTP is concerned is an error. There doesn't seem a great need to tell HTTP there's an error, HTTP doesn't really care. Telling the browser there's an error has some marginal utility, but if it's an API and there's no browser involved, that doesn't matter much either. The 200 isn't going to fool it into thinking it should put the error into the history or whatever.
I've also learned to avoid getting too fancy with the codes. You will invoke some weird behaviors from systems you didn't even know cared about your connection. 200 {"error": "..."} may seem "wrong", but it is also generally safe. It will do what you expect.
It might be nice to live in a world where there are HTTP error codes that are suitable for everything I need, instead of a big pile of useless codes for abortive standards that never came to be and things nobody uses, and an underspecified set of codes for the things I actually want and use, but there's no point pretending that the standard is something other than it is, and as it stands now, a lot of times the HTTP result code is almost useless.