jiebi/CodeConvo huggingface dataset:
These are probably just implementation bugs, but it's somewhat curious that no browser handles from the standard correctly. They all do handle correctly on the other hand. I'll create some manual tests for web-platform-tests, unless someone has a good idea on how to automate this...
At it's defined by and by with But in the it is: :confused:
What exactly do you mean by "but"?
You're right. My fault. I didn't read the correctly. Where is the alternative defined? Thank you for your assistance.
See URL and the links from there.
Thank you and sorry for the noise.
Basic manual test at URL including links to browser bugs (all browsers fail).
When I wrote tests around seven years ago, Konqueror was fixed to pass most of them. That seems to indicate that it's possible to implement the spec.
Oooh, can we convert those to web-platform-tests somehow, even if only manual for now? (I got some pushback from at least one Firefox developer on fixing this and given it's HTTP authentication I suspect most people won't be too enthused, but it also seems worth fixing as having separate parser requirements for any header between a single comma-separated and two headers is just bad and not really compatible with how HTTP is defined.)
Feel free to steal from URL ...
While it's possible to implement the spec, given that none of the browsers implement it and doing so won't really make anything possible that isn't possible now, could we limit to one challenge per header?
In HTTP, intermediaries are allowed to coalesce multiple field instances into a single one, no matter what the field name is. So if you have two header instances, it's legal to combine them into a single one. RFC 7230 made one exception for cookies, because they break otherwise. We looked at WWW-Authenticate and verified that no exception is needed here. So my position remains: implement the spec, or otherwise prove that it's impossible/would break existing use cases.
I'm the one Anne talked to. He's right, I'm not particularly excited about the idea of making this change - none of the browsers handle it right now, and with the ambiguity around commas in the grammar, making this change is on the higher side of the "likely to introduce terrible bugs" scale. Not to mention there may be intermediaries somewhere that depend on the current behaviour.
Changing this could also result in interop issues there, which will be much more difficult to fix than upgrading clients. Given all that, this seems like a case where changing the spec would be more appropriate.
How exactly would those be affected?
Even if you change the standard, some browsers might still have to change their code as URL indicates that, e.g., parses differently across browsers. That doesn't really seem like an acceptable outcome whatever we do.
FWIW, that's a parse error according to the ABNF. EDIT: in the meantime I realized that the syntax is ok.
NAME : Currently one can embed a comma somewhere in the auth challenge. These will break if browsers change behavior. Given how long this bug has been around, it's difficult to estimate the effect of such a change. Both FF and Chrome have telemetry, but at least from the perspective of Chrome, we don't have much insight into many corporate or closed networks where middle boxes tend to be much more prevalent. The change itself is fairly trivial from a code perspective. And I understand that either option isn't great. However IMHO the reward doesn't seem to justify the risk of changing browser behavior here.
No, it doesn't, if the parsing is done correctly. Please give an example if you think otherwise.
I don't know, and that's what scares me. Intermediaries have all kinds of busted behaviour already, and changing the way the WWW-Authenticate header is parsed in practice (spec notwithstanding) could have unintended consequences (dropped as a malformed header is the first possibility that comes to mind).
It would be helpful if you gave at least one concrete example.
HTTP is not defined by browser behavior after receipt of a valid message. Even if five major browsers caught fire and imploded upon receipt of multiple challenges, that would only increase the need for those parsers to be fixed (somehow). We can't control the bits received. The easiest fix is to simply parse the field as specified, since that's what the non-browser UAs have been doing for ages.
NAME unfortunately I can't, as I have neither the time nor the resources to test even the most common intermediaries. I've just been around long enough to not trust them to not be doing something horrible. NAME your hyperbole is not at all useful here, thanks.
I'm glad you're confident in all the major browser vendors being so perfect as to not accidentally introduce some corner-case parsing bug that is potentially catastrophic for the security of WWW-Authenticate. I would prefer to be conservative, and recognize the fact that this is the way the internet has operated for years (decades?) and we're probably better off taking the safe course of changing the spec over changing every single browser on the planet's handling of a security-sensitive header.
NAME What hyperbole? Changing the spec is not a "safe course", no matter how you look at it. There exist cases where multiple schemes are in use today. There exist many intermediaries that will, without question, merge those multiple field names into a single field value regardless of sender's choice to send multiple fields. There exist many clients (e.g., API clients) that currently support multiple auth schemes and choose one, which is the primary audience for this bit of the protocol. The only question here is what should a browser do given the same bits received. Regardless of that answer, the spec will not be changed.
OK, if the answer I give doesn't matter, and the spec won't be changed, then no point engaging.
We cannot change HTTP (for which there exist thousands of independent implementations) just because a few browser implementations choose to ignore a valid header field value. We can only make a change when all deployed implementations do the same thing, or when failing to implement it correctly is either impossible or known to be insecure. Servers compensate by not delivering the same options to bug-present user agents that they do for API clients, or rely on a TLS connection being sufficient to prevent most intermediaries from joining field values (which can lead to gateway/CDN issues, etc.). This has never been good for the security of browsers. They get stuck with Basic while the rest of the HTTP universe is using better auth schemes. Nevertheless, we can't change the spec to prevent header field joining, which deployed implementations have always done, nor can we disallow multiple auth schemes that current APIs depend upon. Hence, an implementation can choose to magically ignore some parts of the field and occasionally fail to support certain (usually more secure) auth schemes when an intermediary is present, or we can get past the FUD and just implement the field as specified. That is an implementation choice, not a spec choice.
FWIW, I believe there is some confusion about what a conforming client is supposed to do. Hint: it's not "splitting where a comma is". That's why I'm asking for examples.
NAME if I'm not totally wrong a is not allowed within a only in a (double) quoted string So parsing is not straight forward "splitting where a comma is".
NAME - that is true, but it is allowed in a parameter value (when using quoted-string syntax). FWIW, this syntax is common across many many HTTP header fields. A common parser library should do the trick.
NAME definitely, do parsing not by yourself. But I've no idea how many libraries/frameworks does it correctly beside of browsers.
Let me just gently remind the audience here that authentication if anything is possibly even more widely implemented and used in and by non-browser HTTP user-agents. Then, I could add that curl also doesn't parse these headers "correctly" and assumes multi-line. And I don't think we've ever had a bug report about it...
I believe this issue should be closed with no action.
NAME does "assumes multi-line" mean "only supports multiple challenges if they're on different lines"?
ah yes, exactly.
I think the options available to us are: Do nothing (i.e., close this issue without action) Include text advising that putting more than one on a header field line may not be interoperable Create a formal exception for (like Cookies)
I don't see why a formal exception is needed; the situation is different from Cookies (cookies do not work without the exception, but WWW-A does). My preference is (1), but I could be persuaded to do (2).
Does anyone object to (2)? If so, why?
HTTP/2 requires clients to support the gzip content-coding. The justification for this has always been that it helps avoid intermediaries and other interposed software (e.g., virus filters) that strip Accept-Encoding to avoid the pain of decompressing responses. However, it has been pointed out that doing so means that intermediaries that translate from 1 to 2 are now required to synthesise new entity tags for decompressed responses, breaking semantic transparency and/or losing significant HTTP functionality.
See also .
It also requires to rewrite ETags in request headers (conditional ones), which is an open-ended list. Furthermore, ETags also appear in payloads (WebDAV properties, for instance).
The outcome of this issue also affects
Discussed in NYC; will remove implicit gzip from spec; may create new content-coding required status code or other strategy (non-blocking).
NAME - can you take a look?
Migrating .. Julian:
NAME NAME per URL, how about... Does that make sense? Would appreciate your guidance on this one :)
I'm starting to wonder if Client Hints should adopt Structured Headers to avoid having to deal with these sorts of questions. Ilya, WDYT?
NAME that would hit a major reset on all existing CH implementations and set us back another couple years, I don't think this is the right call for CH. /cc NAME Surely CH is not the first instance where we had to spell out behavior for selecting one out of N header values? That said, if we don't have established verbiage for this, I'm happy to just make up some language ourselves to clarify how it should behave.. what we're aiming for ain't rocket science. :)
I wouldn't want to set CH back that much (although it is lingering on :). I only mention it because all of the defined syntax seems like it would easily fit into SH, and Chrome already has a good start on a SH parser, thanks to NAME work on signed exchanges, etc.
As an aside, the same clarification should also apply to response headers. Currently Chrome treats multiple responses headers as an error and ignores both.
NAME my preference is to get this over the finish line without introducing dependency on SH. For one, we're also relying on Feature-Policy for delegation and we decided against SH there. WDYT of suggested text in URL — warmer? NAME ack.
NAME I hear you. My thinking is: We've already waited a good while for CH, and it's not clear that it's really really done yet (I suspect we have at least one more round of doc review). People are already using CH as a framework for new hints, so getting SH in would be best now if it's going to get in. If CH are going to be commonly sent, having well-defined parsing behaviour and the possibility of better serialisations (which SH gives us) is very attractive. To be clear -- this is me as me, not me as chair.
NAME - could you clarify what you mean by CH adopting SH? Do you mean that the / headers would be defined as /? Or that they'd be define as with extended processing model (which guarantees that the last item in the list "wins")? Or something else altogether?
Both and could be s. would be a of s. Both and would be s. would be a . I'm not really sure why its current ABNF is a list. NAME Considering that parsing and serialisation algorithms for these haven't been defined yet at all, I don't think it would take a lot of work (and would be happy to do a PR).
Good catch, I think that's an oversight and we can fix that. Stepping back, my preference is (still) to proceed at this stage without introducing dependency on SH. First off, introducing SH does not address the issue we're actually trying to solve in this bug. Second, it adds another significant dependency to CH adoption that I would like to avoid at this stage, as it's yet another reason for a browser vendor to drag their feet and delay integrating support for SH. To get CH over the last call barrier, I believe we have two outstanding tasks: Clarify Accept-CH-Lifetime definition, per above. Provide some minimum guidance on how to deal with aggregated values — see URL I don't think we'll land on perfect text for (2), but this is not a unique or new gap vs other and existing specs, and I don't think we should block on this. NAME does this sound reasonable?
friendly bump :-) NAME NAME PTAL, any thoughts or guidance on the above text?
The issue is that it's defined to only have one value. I think you'd need to say something like: Or, to really define it, define an algorithm.
This was discussed at the HTTPWG meeting today and it was decided to go ahead with Structured Headers!
Based on group discussion at IETF, everyone is on board.
only one "on" value is recognized today allow parameters on token Discussion: URL NAME NAME can you please do a quick sanity check?
NAME thanks, updated! getting warmer?
Think so. NAME is the Keeper of the ABNF, though.
NAME NAME thanks. Updated, do you want to do a last sanity check before I merge?
Looks good to me.
I understand that the current method has the save-data aspect of client hints as a simple on/off switch. I wonder, though, about the willingness to consider allowing for some extensibility. Right now, someone saying "save-data=on" is signing up for pretty much anything. Separating acceptance of data saving for different elements, e.g. agreeing to smaller video resources but not lower fidelity audio, seems like it may be useful. I suggest that the working group consider making this an extensible field with "save-date=all" as the default, with semantics matching the current "save-data=on". Then later extensions can be specified for more granular statements.
I think we can already achieve this with current definition: We can define other tokens We can define parameters - e.g. "on;video-only", etc. Changing from "on" to "all" doesn't really change anything. Also, we already have both client and server implementations that are relying on "on". p.s. some background: URL
NAME - any further comment?
I think the parameter method would be quite useful, and if the doc describes that it would be useful. I'm less sanguine about introducing parameters later, but I certainly wouldn't fall on any sharp objects if that were the decision of the WG.
I guess we should clarify that it is extensible and define "on" as one of its recognized values... Does that make sense? I'm sure my ABNF is off.. :)
, Ilya Grigorik EMAIL wrote: regards, Ted
Resolved via .
Is there a reason to use semicolon here instead of the more typical comma? Also, the grammar does seem off: it does not allow whitespace (because the “implied ” rule of RFC 2616 no longer applies), and it uses instead of .
Assuming you really want semicolons, I think it should be: (I can file a separate issue if you want)
I wouldn't say comma is "typical" -- it depends a bit on the use case. For instance, alt-svc uses a list of comma-delimited directives, each of which can have semicolon delimited parameters. In any case, if this does not use commas, the spec ought to state what happens when commas turn up in a field value, or if a field occurs multiple times in a messages (this is stated for the other client hints).
That, indeed, was the intent - e.g. "on;video-only". Re, OWS: good catch. Addressed in URL
minimalist attempt at a fix for
Thanks for the review NAME I've incorporated all your suggestions.
Thanks NAME and NAME I dare say it's okay merge? (thinking about the I-D submission cutoff in a few hours but admittedly don't know what else could/should go into -15 or if publishing that today is even on the table)
I don't believe this example given in particularity well reflects the situation that precipitated the behavior described in : It's only an explanatory example so arguably doesn't even really matter. But RFCs are forever and they are often cited so it'd be nice to have this bit of the historical narrative better reflect the realities at the time (I say this mostly from perspective of having experienced some of the difficulties caused by the introduction of SameSite cookies and their default enforcement mode and, to this day, continuing to have challenging conversations on the topic). As best I can recall, login type flows were the main driver for the "Lax-allowing-unsafe" default mode but the need manifested itself more in the later part of the flow where the authenticating site (IDP) caused the browser to make a POST request callback to the site requesting authentication (RP). At the start of the flow, prior to sending the user to the IDP, the RP would typically set a cookie with or referencing some transaction specific state and use that info during processing of the callback for validation of the token provided by the IDP. Cookies with Lax as the default enforcement mode would not be sent with the callback POST request and the whole login flow would fail. The "Lax-allowing-unsafe" default mode (aka "Lax + POST mitigation") allowed those flows to not break for a while and gave RPs (and their vendors, frameworks, etc.) a little grace period to update to explicitly designate those cookies as SameSite=None. Could we augment or replace the example described in to account for all that? The cookie age stuff in , I think, makes more sense in the context of the above too. I'm (obviously) having trouble articulating some of this so including some "helpful links" here too, which may or may not describe some of this better.
Chromium called it the "Lax + POST mitigation" where the cookie would have a CSRF token: URL This explainer by some Googlers describes some of this in Top-Level Cross-Site POST Requests: URL and links to this payment flow which is very similar to the login flow: URL The question in this issue on kinda related stuff came back to my attention very recently, which is what led me to looking at these parts of RFC6265bis again. Which maybe explains some of why I'm putting in this annoying issue near the very end of WGLC. Or explains the timing anyway. URL
To clarify, You'd like the example to be one which is closer to a real world case? Namely FedCM (guessing from your use of "RP", "IDP", and the issue on the repo). I'd like to avoid getting too specific and in the weeds but there's probably a way to generalize the FedCM case. Contextualizing the cookie age also seems like a positive to me, its relevance isn't super clear otherwise.
Yes. Apologies if that wasn't clear from my rambling above. And to try and be more clear, I'd like the example to be one which is closer to the real world cases that gave rise to the Lax-allowing-unsafe mode. No, namely SAML with the authentication response delivered with the POST binding. Or OpenID Connect using the where the '' is needed to validate the returned ID token. Agreed about not getting too specific and in the weeds but think the SAML/OIDC cases could be generalized too. Although I tried to do that in the issue description here and didn't seem to be too successful in conveying the concept. In my mind it makes a lot more sense in the context of a short term cookie used for transaction specific state and validation. And doesn't make a lot of sense in the context of "cookie[s] with login information". I guess my hope is that it would just be better contextualized by way of using an example that's more reflective of the historic occurrence. But more contextualizing, if needed/appropriate, would certainly be okay by me too.
NAME could you propose a diff to the paragraph: Or is it sufficient to just tweak the first sentence of that paragraph?
For someone who is not super familiar with SAML authentication flows ( , it's me), what exists in the draft text today feels like a fuzzier higher-level description than: It's entirely possible that's the only pattern that motivated Lax-allowing-unsafe, but maybe not - the web is messy. Maybe a compromise here is to tweak the text to cover your example generally (as well as other examples sitauations to ~POST w/ a cookie expecting some login information), and go super precise in the commit message. Just a thought.
It'd be a bit more involved than just the first sentence but I'm happy to take a stab at reworking that paragraph and maybe a few other very minor related things, if the authors/WG are amenable to the idea? Not to be expected :) The OpenID Connect flow is probably more salient but familiarity there isn't expected either. The important distinction (to me anyway) is where the cookie in question would be sent (or not sent), the associated failure mode, and the effectiveness of the mitigating default mode. With what exists in the draft text today, the cookie is holding/referencing login state that's sent to the site that will authenticate the user (maybe based on an existing session identified by that cookie). If the cookie isn't sent (due to default of Lax and a x-site POST style redirect), the failure mode will usually be the user needing to enter their login credentials again. Which is annoying but recoverable. Also the Lax-allowing-unsafe applicability to "cookies which were created recently [~2 mins]" doesn't help in many many cases for cookie that's used for login state due to such cookies being relatively long lived (not created recently) and/or the user not having even visiting the site recently. With the pattern I'm (trying) to describe, the cookie is holding transactional state that's sent back to the site requesting authentication after user authentication. If the cookie isn't sent (due to default of Lax and a x-site POST style redirect back to the originating site), the failure mode will usually be an unrecoverable error for the whole login flow.
The Lax-allowing-unsafe applicability to "cookies which were created recently [~2 mins]" is quite helpful in this case because that transactional state specific cookie will typically be set right at the beginning of the whole login flow and only needs to live as long as it takes for the user to complete the login journey. Oh yes, of course, it's very messy. I'm sure it wasn't the only pattern that motivated Lax-allowing-unsafe but I'm almost as sure that it was the primary pattern that motivated it. Let me see if I can tweak the text to cover things generally (without screwing it up) and the commit message can reference this issue to link back for more info?
Hi NAME Have you had any progress?
I'm sorry NAME probably my fault in the way I left the prior but I wasn't sure if I was supposed to be working on a PR or was waiting for an okay from you/WG/etc to do so. And in the intervening time my attention for it was sort of overtaken by events. Apologies again and I'll try and do something soon.
URL is a minimalist attempt at some adjusted text for this
LGTM, thanks! I'll wait for NAME to take another look before mergingCatching up on things after being out sick: this still LGTM. :)
Attempt to reword the 'Header Block Size' section to use more HTTP version neutral terms (for )
Is this a hangover from terminology changes elsewhere? URL says
Very possible that it's a hangover from terminology changes elsewhere. Very possible. But I'm not quite sure how to update it. HTTP/3 talks about the "size of the message header" (from your reference) while HTTP/2 talks about block size but now uses field block size URL rather than header block size URL How about the following though? Assuming I'm even adjusting the terminology you're suggesting needs adjusting. Message header seems more neutral and appropriate.
Thanks for the suggestion and PR. I think we're best off holding for NAME review since he had to do a similar renaming exercise for HTTP/3 and is an expert now
Makes sense. I, for one, would welcome such expertise.
URL Mike okayed it
Yes, this looks reasonable.