- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 25 Feb 2026 08:16:23 +1100
- To: Ted Hardie <ted.ietf@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Ted, > On 24 Feb 2026, at 7:20 pm, Ted Hardie <ted.ietf@gmail.com> wrote: > > Hi Mark, > > I've read the linked context and the draft, and I am concerned that this will cause folks to simply drop the Sec-Purpose header with pre-fetch; tying the result to that seems pretty fragile. Some context might help. Sec-Purpose is added by browsers when they prefetch/preload, based upon things like hints in the HTML and Speculation Rules set by the site. When a server refuses the prefetch/load, they're basically saying "in this particular instance, I don't think this preliminary request will actually improve your performance, and may hurt it, so I'm not sending you a response" -- usually because the server has better information at request time than it did when it generated the hints/rules. So, this is a cooperative use case -- it doesn't risk the client trying to work around the denial. > The approach described in 503 with retry-after seemed pretty compelling, and if it were not for the customer issues you raised, I would have suggested that you pursue that. Given those are focused on 500 series responses, would you consider 4xx with a retry-after, which could be used both in the case you mentioned (pre-fetch) and whenever else the server felt a resource would be available at a specific point? That has the same issues as we encountered with other status codes - the risk of confusion with the other use cases for the status code. Personally, I'm reluctant to mint status codes for such specific use cases *unless* they have significant deployment; we seem to be in that category now. Cheers, > > regards, > > Ted > > On Tue, Feb 24, 2026 at 12:24 AM Mark Nottingham <mnot@mnot.net> wrote: > (without my 'chair' hat on) > > I'd like the WG to consider adoption. See here for context: > https://github.com/WICG/nav-speculation/issues/138 > > Cheers, > > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-nottingham-httpbis-pre-denied-00.txt >> Date: 24 February 2026 at 10:18:02 am AEDT >> To: "Mark Nottingham" <mnot@mnot.net> >> >> A new version of Internet-Draft draft-nottingham-httpbis-pre-denied-00.txt has >> been successfully submitted by Mark Nottingham and posted to the >> IETF repository. >> >> Name: draft-nottingham-httpbis-pre-denied >> Revision: 00 >> Title: The Preliminary Request Denied HTTP Status Code >> Date: 2026-02-23 >> Group: Individual Submission >> Pages: 4 >> URL: https://www.ietf.org/archive/id/draft-nottingham-httpbis-pre-denied-00.txt >> Status: https://datatracker.ietf.org/doc/draft-nottingham-httpbis-pre-denied/ >> HTML: https://www.ietf.org/archive/id/draft-nottingham-httpbis-pre-denied-00.html >> HTMLized: https://datatracker.ietf.org/doc/html/draft-nottingham-httpbis-pre-denied >> >> >> Abstract: >> >> This specification defines a HTTP status code to indicate that the >> server is denying a prefetch or preload request. >> >> About This Document >> >> This note is to be removed before publishing as an RFC. >> >> Status information for this document may be found at >> https://datatracker.ietf.org/doc/draft-nottingham-httpbis-pre- >> denied/. >> >> information can be found at https://mnot.github.io/I-D/. >> >> Source for this draft and an issue tracker can be found at >> https://github.com/mnot/I-D/labels/pre-denied. >> >> >> >> The IETF Secretariat >> >> > > -- > Mark Nottingham https://www.mnot.net/ -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 24 February 2026 21:16:31 UTC