[headers] Add the "304" headers (ETag and friends)

[skabbes]

Context I currently don't use any remix-the-web libraries, but after hearing about them on the remix roadmap planning, I am evaluating the headers lib. I realized that it didn't have the all the headers I needed.

I am building a little remix app that syncs from arbitrary iCalendar feeds. In order to be a good citizen of the web (and save my own bandwidth), I would like to send conditional requests to the upstream servers with If-None-Match (if the previous response had an ETag), and an If-Modified-Since (if the previous response had a LastModified).

Additionally, I'd like to respect the upstream server's cache-control headers as well, but I think everything I need is already here.

Request Add headers to this library for:

• Etag
• If-None-Match
• Last-Modified
• If-Modified-Since

I'm happy to help on this, but no ego about doing it myself (if think this is a good idea, @mjackson just go for it).

Discussion New remix-the-web package?? Cache + Cookies?

In addition to these changes in the headers library, there might be an opportunity here for a server-side Cache. I could see this being a common building block of "I want to make requests on a server, but doing all the "normal" stuff that a Browser would do out of the box (in terms of caching, cookies, etc)".

I see this as being a "Cookie Jar" + "Cache implementation", and integrated into fetch somehow (I can tell fetch us use this context for a fetch). Similar to the file-storage package, this would probably need pluggable persistence. In my use case, I'd need this to be durable in Redis / DB / etc.

[sergiodxa]

Regarding Cache, I built a POC some years ago, and tried it, but it's too limited IMO to use it server-side.

If you're only fetching an API it may be great since you cache the response associated to a request, but if you query your DB, or even use an API but through a SDK (Like Octokit) then you don't have a Request and Response to cache. And while you could create one of each it's adding extra runtime cost.

I think a CacheStorage API should be more generic, like lru-cache package API, not associated with the Fetch API, specially to be used server-side.

---

For Cookies, the Remix Cookie API is great IMO, not sure if they want to move it here or keep it as part of Remix/RR.

[skabbes]

Thanks Sergio, I do agree that a lot of use cases will need a more general purpose cache, but I think there are plenty of existing libraries for that already in existence. I'm not really talking about that.

What I mean is "allow caching to work in a server context the same way it does in a browser context". So if I write a bunch of code that works in the browser (including receiving cookies, and having them sent back up when I make future requests), then maybe there is a way to make that same code work on the server. I think that would require cookies, and caching (and I'm sure a few other things I'm not thinking of).

Being honest with myself on my particular use case, I'm not sure I would use it myself either - but thought I'd raise it because it definitely fits the philosophy laid out here and in Remix too.

[mjackson]

Hey @skabbes, nice to meet you. Thanks for the issue.

As for the headers you'd like to see implemented, I'm :+1: all the way. The goal for the headers lib is to have support for all common http headers, and all the ones you mentioned are definitely in scope. I've got a few things going on right now, but if you don't get to it either I or someone on the Remix team will eventually.

As for a first-class server cache API I'm also 👍 on that. It should have a pluggable "fetch storage" API (similar to what we're doing with the file-storage lib) so users can cache stuff in various backends.

I see this as being a "Cookie Jar" + "Cache implementation", and integrated into fetch somehow (I can tell fetch us use this context for a fetch). Similar to the file-storage package, this would probably need pluggable persistence. In my use case, I'd need this to be durable in Redis / DB / etc.

Yep, that 😅

Regarding Cache, I built a POC some years ago, and tried it, but it's too limited IMO to use it server-side.

@sergiodxa It would mostly be useful in either "offline" apps or proxies. Most likely not terribly useful in normal SSR scenarios.