- From: Rory Hewitt <rory.hewitt@gmail.com>
- Date: Wed, 5 Feb 2025 08:58:33 -0800
- To: Mike Kistler <mikekistler@microsoft.com>
- Cc: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAEmMwDxoyv5=APNXVauGT585czUkkr_tRy6zkkW4LzD0B2agaQ@mail.gmail.com>
> The RFC does not document what to do when you don't follow the RFC. Yup. Well, more accurately "Any specific RFC does not document what to do when you don't follow that specific RFC." The phrase "the RFC" is very misleading to me - while there are *some* RFCs like 9110 which are very general and underpin all of HTTP communications, there are, as you well know, many RFCs that are far more specific - many of which I've never heard of or looked at. On Wed, Feb 5, 2025 at 3:35 AM Mike Kistler <mikekistler@microsoft.com> wrote: > > AFAIAC, there's basically no reason (IMO) to include a "If a server does > not support > > header If-YouFeelLikeIt, then it SHOULD respond with X" section in the > RFC which > > defines If-YouFeelLikeIt - it will never be used by servers that don't > support > > If-YouFeelLikeIt. > > Agreed. This makes perfect sense and does answer my original question. > The RFC does not document what to do when you don't follow the RFC. > > Mike > > From: Rory Hewitt <rory.hewitt@gmail.com> > Date: Tuesday, February 4, 2025 at 4:21 PM > To: Mike Kistler <mikekistler@microsoft.com> > Cc: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>, > ietf-http-wg@w3.org <ietf-http-wg@w3.org> > Subject: Re: [EXTERNAL] Re: Response for unsupported conditional request > > You don't often get email from rory.hewitt@gmail.com. Learn why this is > important <https://aka.ms/LearnAboutSenderIdentification> > Mike, > > I think it's also a requirement to point out that many RFC's are not > always well-written and some make numerous assumptions. Despite the best > efforts of the IETF. > > To go back to your original point: > > > Is there a required or recommended response that a server should give > if it receives a request with a conditional header (If-Match, If-No-Match, > If-Modified, If-Unmodified) that it does not support? > > There is clearly a required or recommended response if the server supports > the header, as defined in the RFC - we all agree on that. > > If the server doesn't support the field, then the RFC may suggest a > response, but there's obviously a good chance that the server was written > without referring to the RFC, so the server has no idea what that suggested > response is. > > To use your example, if a server was written to follow RFC9110, but prior > to the RFC which defines your hypothetical If-YouFeelLikeIt field, then not > only does it obviously not support If-YouFeelLikeIt, but it has no idea > that If-YouFeelLikeIt even exists, so it has no idea what to respond > with... So all you can do in your RFC is include instructions for what a > user agent should do if it sends the If-YouFeelLikeIt field and gets > nothing specific in the response. > > AFAIAC, there's basically no reason (IMO) to include a "If a server does > not support header If-YouFeelLikeIt, then it SHOULD respond with X" section > in the RFC which defines If-YouFeelLikeIt - it will never be used by > servers that don't support If-YouFeelLikeIt. > > On Tue, Feb 4, 2025 at 1:54 PM Mike Kistler <mikekistler@microsoft.com> > wrote: > >> > I think you may have a misguided assumption that all RFCs are >> >> > somehow strictly enforced everywhere. They are not. >> >> >> I do not have this assumption. I am simply trying to understand what it >> means to be compliant with the RFC. When I read the language I cited, it >> seems to me that origin servers "MUST" implement the behavior described or >> they are not compliant with the RFC. If that is not the case, I would >> appreciate being educated on why that is not the case. What wording have I >> missed or misunderstood? >> >> >> > Multiple reasons have already been given. I'll repeat one: >> >> >> > This is the nature of a heterogeneous internet with clients and servers >> >> > of widely varying ages, protocol support, and simplicity/complexity. >> >> >> I can understand that this is why some origin servers do not comply with >> the RFC. But this is not what I'm asking. i want to know what it means to >> be compliant. But maybe you mean that for this reason it is not necessary >> to follow the "MUST" provisions to be compliant with the RFC. I hope you >> don't mean that, because in that case it seems that all servers are >> vacuously compliant which is not particularly useful. >> >> >> Mike >> >> > > -- > Rory Hewitt > > https://www.linkedin.com/in/roryhewitt > -- Rory Hewitt https://www.linkedin.com/in/roryhewitt
Received on Wednesday, 5 February 2025 16:58:49 UTC