RE: Possible need for new 3xx status code Temporarily See Other

On Wednesday, September 25, 2024 8:42 PM Willy Tarreau wrote:

> To: Belov, Charles <Charles.Belov@sfmta.com>
> Cc: ietf-http-wg@w3.org
> Subject: Re: Possible need for new 3xx status code Temporarily See Other
>Hello,

>On Wed, Sep 25, 2024 at 11:37:37PM +0000, Belov, Charles wrote:

>> This is a comment on HTTP/1.1, part 2: Message Semantics
>> draft-ietf-httpbis-p2-semantics-16
>>
>> We have a situation where, to prevent server overload, we temporarily 
>> can't serve the desired resource but can serve a related resource that 
>> may be helpful. We don't want search engines to register this as an 
>> update to our website.
>>
>> We have settled on 307 Temporary Redirect. But that's not accurate, 
>> because it's not a temporarily moved resource, it's a substitute 
>> resource. So 303 See Other would in theory be more appropriate.
>>
>> But 303 See Other might be taken as stating that the requestor should 
>> ask for this other resource in the future, which might cause search 
>> engines to update their index, which we don't want to happen.
>>
>> It would be nice to have a 3xx status code for Temporarily See Other 
>> to get across that we are only serving this other resource temporarily 
>> and that future requests should be for the original request.

>Just an idea, but wouldn't an Expires response header field suffice to limit the 
>validity period of the 303 ?

>Regards,
>Willy

First, let me correct the original resource, which has been issued as HTTP Semantics
RFC 9110 at https://datatracker.ietf.org/doc/rfc9110/. I will also refer to HTTP Caching RFC 9111 at https://datatracker.ietf.org/doc/html/rfc9111#name-expires.

9110 makes it clear under 15.4.8. 307 Temporary Redirect for a 307 status code that "Since the redirection can change over time, the client ought to continue using the original target URI for future requests." 

And it does say under 15.4.9. 308 Permanent Redirect that "The server is suggesting that a user agent with link-editing capability can permanently replace references to the target URI with one of the new references sent by the server.  However, this suggestion is usually ignored unless the user agent is actively editing references (e.g., engaged in authoring content), the    connection is secured, and the origin server is a trusted authority for the content being edited." Alas, I cannot be certain that search engines are not engaged in such reference editing.

Which leads me to my fear under 15.4.4. 303 See Other: "A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP." Which is that if an agent treats the 303 request as permanent, that it may make future requests to the new location. But we do have a representation of the original request; we just can't supply it at the moment. We want future requests to go to the original location.

Getting back to your suggestion, 9111 states "The "Expires" response header field gives the date/time after which the response is considered stale." It is not clear to me whether that means the content is stale or the status code is stale (or both). If an agent takes it as the response being stale and will after expiry try again under the original location, then there is no problem. But if an agent which does edit references takes it as the substitute content being stale and not the 303 being stale, it might - incorrectly - update its references and request the new location in the future. 

I supposed we can do as 9111 suggests and use a past date and time for the expiry header, marking it as immediately invalid. Still, I'm not sure I can count on the agent making the correct decision regarding not editing the reference.

It would be nice if 9110's explanation of 303 and 9111's explanation of "expires" were clearer about how agents would best respond.

Hope this helps,

Charles Belov
he/him
Digital Accessibility & Inclusion Coordinator
Founding Web Lead
Communications & Marketing

San Francisco Municipal Transportation Agency
1 South Van Ness Avenue, 3rd floor
San Francisco, CA 94103

Received on Tuesday, 1 October 2024 21:14:31 UTC