Re: [EXTERNAL] Re: Response for unsupported conditional request

If you know the modification date and can compare it to the requested one,
you can return a 304 with the headers that include the actual modification
date. If you don't, you return 200 and the resource without a modification
date. The 412 precondition failed header is for when you understood the
precondition and it didn't apply. The MDN docs are good on this.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests

It makes a GET vs PUT distinction too.

From the requester point of view using GET, I want to receive your
resource, so I expect a 200 response with the resource. If I'm being polite
to you, I'll send an etag and modified date so we can both save bandwidth
if I already have the resource cached , and you can return a 304 with
correct headers for me to update my cache expiry (if you had told me when
it expires originally and I was even more polite, I wouldn't have made the
request at all before the expiration).

Returning a 412 or 5xx doesn't help the requester, as now I don't have a
good answer on the state of my cached copy.

Do I throw it away and retry without the conditions? Do I keep it and
assume you have a bug?

For example, if you return a 404, I would like to keep it and assume you
have problems, but if you return a 410 I probably want to delete it from my
cache (unless I am, say, the wayback machine and want to preserve state at
a previous time)

What I'm getting at is that, for a http GET, the Postelian answer is to
fall back to 200 and send the resource, rather than a draconian reading of
the spec.




On Wed, 5 Feb 2025, 07:16 Julian Reschke, <julian.reschke@gmx.de> wrote:

> On 04.02.2025 18:04, Glenn Strauss wrote:
> > ...
> > A resource served by a server might not generate Last-Modified or ETag.
> >
> > If a server does not generate an ETag for a resource, then the server
> > may not apply If-Match and might ignore If-Match sent by the client.
> > ...
>
> Yes.
>
> But what about Last-Modified?
>
> Best regards, Julian
>
>