Subject: Re: I-D Action:draft-nottingham-http-stale-if-error-01.txt

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 9 May 2008 16:02:16 -0700

Too many frigging bytes.  Define them as sie= and swr=.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 May 2008 08:53:02 +1000

FYI.

This is implemented in Squid 2.7, which should be marked STABLE Any  
Day Now.

I intend to ask this to be published as Informational soon.

Cheers,

Begin forwarded message:

> From: [email-masked]
> Date: 9 May 2008 3:00:01 PM
> To: [email-masked]
> Subject: I-D Action:draft-nottingham-http-stale-if-error-01.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : The stale-if-error HTTP Cache-Control Extension
> 	Author(s)       : M. Nottingham
> 	Filename        : draft-nottingham-http-stale-if-error-01.txt
> 	Pages           : 6
> 	Date            : 2008-05-08
>
> The stale-if-error HTTP Cache-Control extension improves availability
> of some kinds of cached content by allowing servers and clients to
> instruct caches to use stale responses when certain error conditions
> are encountered.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-http-stale-if-error-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Mark Nottingham     http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 May 2008 09:11:36 +1000

Yeah. Anybody else want to weigh in pro or con on this?

---

From: "Brian Smith" <[email-masked]>
Date: Sat, 10 May 2008 14:41:24 -0700

> Yeah. Anybody else want to weigh in pro or con on this?

"In this context, an error is any situation which would result in a
500, 502, 503 or 504 HTTP response status code being returned."

It seems wrong to limit this to these four status codes. Why not have the 
server indicate that stale responses are okay when it returns the error 
response? In other words, instead of returning stale-if-error=XXX on a 
successful response, it would return it in the 5xx responses. Alternatively, 
allow the stale-if-error subfield to list the status codes for which a stale 
response could be returned.

Also, I think that the specification needs to explicitly mention that a 
warning should be added when a cache returns a stale response due to a 
back-end error.

Regards,
Brian

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 11 May 2008 11:06:15 +1000

On 11/05/2008, at 7:41 AM, Brian Smith wrote:

> It seems wrong to limit this to these four status codes. Why not  
> have the server indicate that stale responses are okay when it  
> returns the error response? In other words, instead of returning  
> stale-if-error=XXX on a successful response, it would return it in  
> the 5xx responses.

Because the origin server isn't always the one that generates a 5xx;  
it may be an intermediary along the way (including one that the cache  
is implemented within).

> Alternatively, allow the stale-if-error subfield to list the status  
> codes for which a stale response could be returned.

That's way too complex, and serving a stale representation for a 4xx  
error doesn't really make any sense.

> Also, I think that the specification needs to explicitly mention  
> that a warning should be added when a cache returns a stale response  
> due to a back-end error.

I can add an e.g. (like in swr).

Thanks,

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 11 May 2008 23:22:34 +0200

> Too many frigging bytes.  Define them as sie= and swr=.

The long descriptive names is in line with the HTTP/1.1 defined
cache-control names. I am not sure it's a good idea having an extension
suddenly use confusing acronyms..

Sure, HTTP is way to descriptive in it's headers, no argument there, but
compressing HTTP is not a topic for HTTP/1.x.

Regards
Henrik

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 13 May 2008 11:23:19 +0200

> Yeah. Anybody else want to weigh in pro or con on this?

Well, apart from the obvious:

stale-if-error: consistent naming with other cache control directives
sie: saving 11 octets

it comes down to the usual fight between good taste and efficiency,  
or? Java and C naming schemes, UNIX and Windows, BMW and Mercedes  
Benz, Mars and Venus. Some would say "stale-if-error" is more girlie  
and "sie" is a manly name.

On the other hand, legend has it, that D. Ritchie, when asked what he  
would do different in UNIX, said: "Well, I would name it create()  
next time."

Hell, if I know. Throw a dice.

//Stefan

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 13 May 2008 10:33:52 -0700

Upon further review, I see no reason for this extension.

>    In this context, an error is any situation which would result in a
>    500, 502, 503 or 504 HTTP response status code being returned.

5xx errors are intended to authorize client-side workarounds, including
the delivery of stale content.  That is, in fact, the only real  
difference
between 4xx and 5xx codes.  If this needs to be clarified in the httpbis
drafts, then it should be an issue on httpbis.

We don't need a cache-control option to authorize what should already be
authorized by the HTTP status code.

....Roy

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 13 May 2008 18:44:47 +0100

Roy T. Fielding wrote:
> 5xx errors are intended to authorize client-side workarounds,
> including the delivery of stale content.  That is, in fact, the only
> real difference between 4xx and 5xx codes.  If this needs to be
> clarified in the httpbis drafts, then it should be an issue on
> httpbis.

If this is intended, it definitely needs clarification.

  1. I had no idea this was intended, despite reading the RFCs.

  2. I'm not aware of any clients which do that, suggesting their
     authors didn't think so either.

  3. On the server side, 5xx error codes are often used to indicate
     faults in the server logic (things like couldn't generate a page,
     broken database, etc.) and nearly always _intend_ browsers to
     show users the error page which is sent, and definitely not stale
     content.

  4. What you've said suggests servers should send 4xx error codes for
     conditions like "server unable to generate page when moving
     between forms, here is an error page explaining why you cannot
     proceed right now".  But which 4xx code?  It's not a client error.

> authorized by the HTTP status code.

In which case, we either need a cache-control option to _unauthorize_
it, or new 4xx error codes to indicate server faults for which the
client should not substitute stale pages.

-- Jamie

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 May 2008 08:09:42 +1000

This extension doesn't authorise serving stale content, it just hints  
that doing so is desired, and explicitly bounds it in time. Clarifying  
the "carefully controlled circumstances" may be in-scope for httpbis,  
but defining the extension for bounding it -- which, with my Yahoo hat  
on, we need -- isn't.

This is covered in the first sentences of the draft.

On 14/05/2008, at 3:33 AM, Roy T. Fielding wrote:

> including

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 14 May 2008 00:00:51 +0200

>      proceed right now".  But which 4xx code?  It's not a client error.

I don't quite get what you mean by "moving between forms" but here is
some suggestions:

403. Request made sense, but your current state does not allow this. You
need to take these actions first.

Or if not that then 409 is also a good candidate. Request made sense but
current server resource state conflicts with the expected state for the
request.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 13 May 2008 23:45:47 +0200

>   1. I had no idea this was intended, despite reading the RFCs.

It's there, but somewhat conflicting and inconsistent.

p6 3.1 Cache Correctness

3.  It is an appropriate 304 (Not Modified), 305 (Use Proxy), or
       error (4xx or 5xx) response message.

   If the cache can not communicate with the origin server, then a
   correct cache SHOULD respond as above if the response can be
   correctly served from the cache; if not it MUST return an error or
   warning indicating that there was a communication failure.

5xx should not be in point 3 there, as 504 is "can not communicate", and
semantically any 5xx is "can not communicate/service this request".

>      authors didn't think so either.

Squid does.

What the stale-if-error extension adds to Squid is bounds, limiting when
this may happen.

> client should not substitute stale pages.

Which is one application for the proposed extension.

Regards
Henrik

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 14 May 2008 00:45:26 +0100

> current server resource state conflicts with the expected state for the

I'm thinking of "4?? Request cannot be serviced at this time due to
server fault.  Responses previously served (i.e. stale in cache) on
this form query URL (a function of entered data only, not whole server
state) are incorrect at this time due to server state changes since
the previous time.  The stale in cache response should not be used, it
would be misleading.  The error response you have been sent may be
useful."

-- Jamie