jiebi/CodeConvo huggingface dataset:
Code change:
. <del> 9.3. Clients MUST support GZIP compression for HTTP response bodies. Regardless of the value of the accept-encoding header field, a server MAY send responses with GZIP encoding.  A compressed response MUST still bear an appropriate content-encoding header field. This effectively changes the implicit value of the Accept-Encoding header field (HTTP-p2) from "identity" to "identity, gzip", however GZIP encoding cannot be suppressed by including ";q=0". Intermediaries that perform translation from HTTP/2 to HTTP/1.1 MUST decompress payloads unless the request includes an Accept-Encoding value that includes "gzip". </del> 10. 10.1.

Related discussion:
text: 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).
Code change:
HTTP cache.  They MAY be made available to the application separately. <del> The server MUST include a value in the </del> <ins> The server MUST include a value in the " </ins> <del> pseudo-header field for which the server is authoritative (see </del> <ins> " pseudo-header field for which the server is authoritative (see </ins> authority).  A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a StreamErrorHandler of type PROTOCOL_ERROR.

Related discussion:
text: I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.
Code change:
techniques to prime the user for an authorization request and thereby trick them into granting authorization.  The social engineering techniques range in sophistication from messages misrepresenting the <del> reason for receiving an authorization request to triggering a large </del> <ins> reason for receiving an authorization request, to triggering a large </ins> volume of requests at an inconvenient time for the user, in the hope that the user will grant authorization to make the requests stop. The figure below shows an example of such an attack.

Related discussion:
text: Changes made in response to issue
User Transfer Pattern -> User Transferred Session Data Pattern Client Transfer Pattern -> Backchannel Transferred Session Patterns Hybrid Pattern -> User Transferred Authorization Data Pattern
Attack naming conventions updated as reflected in merge 0988577895daf3878e3d3de59add470c35c4cc4a
Code change:
mapped defines alternative representations of existing fields. Because downstream consumers might interpret the message differently based upon whether they recognise the alternative representation, <del> implementations are prohibited from generating such fields unless </del> <ins> implementations are prohibited from generating such values unless </ins> they have negotiated support for them with their peer.  This specification does not define such a mechanism, but any such definition needs to consider the implications of doing so carefully.

Related discussion:
text: Sorry for noticing this so late. I don't think the security considerations of in retrofit work out. (Also CC NAME who is much better at web security than me.) If we introduce two ways to spell some field, we need to worry about whether this can allow various issues when sender and receiver don't agree on what's going on. The draft mostly leaves this to the future, but it does include some about this: This seems to put the onus on the sender, not the receiver. If you don't know the receiver accepts the alternate representation, you can't send it. It includes no corresponding receiver obligation, I guess on the assumption that if you see SF-Cookie, you can assume the sender meant it? I don't think that works. In a browser, the sender is a combination of browser logic (which has the final say) and JS (with a complex trust relationship). The browser logic specifies some which JS cannot set. Other HTTP systems have similar splits: an HTTP serving frontend may get fields from a CGI script or act as an intermediary, but it cannot allow the downstream code to specify fields like . These rules typically look like a blocklist with the default behavior to pass fields through. All this is to say, browsers won't let JS set the field directly, but setting is perfectly fine, up to CORS rules. A receiver may see that text and incorrectly assume that processing is fine, breaking some cookie invariants. Or vs , which will break some sites' CSRF processing. Beyond just blocklists, a retrofit-unaware HTTP cache that processes caching fields but passes through other fields will likely make a mess of the mapped caching fields. If we prefixed the names with , that would at least meet the browsers' rules, though I worry it'll still break other intermediaries. It's also a little unsatisfying of a fix. We could say that a receiver cannot process these either unless it's received some explicit negotiation that the sender knows about this. That's vague and unspecified, but probably would work, depending on what the intent is here. This is a bit handwaivy because I'm not sure what the use cases are here. But if we require explicit sender and receiver negotiation, it's unclear what we're getting out the parallel field names in the first place. It seems to me that's where all this risk comes from.
Code change:
mapped defines alternative representations of existing fields. Because downstream consumers might interpret the message differently based upon whether they recognise the alternative representation, <del> implementations are prohibited from generating such fields unless </del> <ins> implementations are prohibited from generating such values unless </ins> they have negotiated support for them with their peer.  This specification does not define such a mechanism, but any such definition needs to consider the implications of doing so carefully.

Related discussion:
text: Giving alternate names interferes with pass-through logic across the pipeline. Maybe we can get a more robust story, inspired a bit by (I'm just assuming this is one of the main use cases here) is to say: The text representation of is what it is. If this part of the system uses the text form, use the existing syntax The structured field representation of is this mapped thing. If this part of the system uses structured fields, use that syntax At boundaries where forms change, convert. We need to be a bit careful about fallibility here, but perhaps: Conversion from text to other forms is allowed to fail, since you can just fallback to the text form. Conversion from other forms to text probably needs to be stricter? The difference between mapped and normal fields is the structured field and text representations don't directly align, so they need to be treated a bit special Like I said, this is handwaivy and definitely incomplete. But it feels to me like something in this might be more sound. It makes it more obvious we have to be sure what representation we're using at each layer and there's no risk of one side thinking something is a generic header and another thinking it's an alternative representation of a special header.
This seems like a plausible risk to me. I'm not as familiar with non-browser use cases, but I can certainly imagine confusion that would result from clients being able to create mismatches between and . I can imagine ways to deal with this in browsers (in addition to NAME suggestions, we could add as a , just as we've done for and ). It's unclear how helpful that would be for non-browser usecases.
Main nuisance with prefix is that, on the receiver side, you don't know a priori if the client is an updated browser, which knows about the prefix, or a preexisting browser which does not. I suppose you could do UA sniffing, but let's not design a system that requires UA sniffing to work if we can help it! :-)
That's fair. would be safe without a change to Fetch. Still, given my expectations about the current deployment of mapped fields, I think we could reasonably get ahead of them in the browser world. Not at all sure about the rest of the ecosystem...
I like the direction that if you've already negotiated support, you could just replace the legacy headers with their spiffy (SFfy?)
Code change:
mapped defines alternative representations of existing fields. Because downstream consumers might interpret the message differently based upon whether they recognise the alternative representation, <del> implementations are prohibited from generating such fields unless </del> <ins> implementations are prohibited from generating such values unless </ins> they have negotiated support for them with their peer.  This specification does not define such a mechanism, but any such definition needs to consider the implications of doing so carefully.

Related discussion:
text: new equivalents using the same names, and if you haven't negotiated support then you have no business sending these variants and expecting them to work. Of course, that means this draft probably can't get away with "We don't define a way to negotiate this, but you do that."
I think we'd avoid needing "OUGHT TO" in that model. That model is more explicit that these are two incompatible representations of these fields. The negotiation requirements become more straightforward, I think: E.g. draft-nottingham-binary-structured-headers meets this requirement because you set a flag on the message, and gates usage on a setting. A hypothetical SF-based HTTP API would also meet this requirement because it's unambiguous that takes some in-memory structured field representation.
Hey David, Yes, I've been somewhat concerned about the potential issues in this area for a while. Minting new field names for the alternative forms was the initial approach, but I was half expecting someone to raise this issue :) One thing: No; the assumption is that a recipient sees SF-Cookie, they'll ignore it unless they've positively opted into it meaning something. Perhaps, as you point out, that should be more explicit -- e.g., say that these fields MUST NOT be processed unless the sender does [magic]. Making sure that evidence of [magic] is propagated properly may be tricky, though. I could also see removing the new field names. That should work for many contexts, although I suspect it might make handling the new forms difficult in some. Prefixing with doesn't seem very attractive to me.
Ah interesting. So I guess the middle option, "require explicit negotiation on the receiver" was actually the intended interpretation. That's not how I read the draft. It says "implementations are prohibited from generating such fields unless they have negotiated support for them with their peer" without saying anything about the recipient's responsibilities. So it sounds like, at minimum, we should update the draft. Getting that right in the presence of a chain of intermediaries is quite subtle however. Suppose we go A -> B -> C and both B and C support mapped fields, but A does not. B must be careful not to forward along a mapped field from A. E.g. it might decline to advertise mapped field support to C because A doesn't support it.
Code change:
mapped defines alternative representations of existing fields. Because downstream consumers might interpret the message differently based upon whether they recognise the alternative representation, <del> implementations are prohibited from generating such fields unless </del> <ins> implementations are prohibited from generating such values unless </ins> they have negotiated support for them with their peer.  This specification does not define such a mechanism, but any such definition needs to consider the implications of doing so carefully.

Related discussion:
text: Or it might reject all mapped field names from A, on grounds that it must have been invalid. Moreover, "intermedaries" has to be intepreted very loosely. Every processing step in the entire HTTP pipeline needs to carefully manage these alternate names. This seems a disaster waiting to happen. I think I'm now convinced this is the only plausible option. Regarding "many contexts" and "some", do you have use cases in mind here? I saw draft-nottingham-binary-structured-headers, but I gather there are others? Something to keep in mind is that this draft intentionally punts figuring out the negotiation design to the future anyway. That means this is also the more flexible option. If we define , etc., now, we have permanently committed ourselves to this security problem. If we decline to define now, we can still choose. We can always define the parallel field names later, should something that needs them come up. (Of course, I'd raise the security problem again, but it'll be easier to reason about with a concrete use case! )
I guess this raises another question: how do we handle mapped field values that cannot be represented in the underlying text representation? Given how many intermediaries and intermediary-like constructs are involved in HTTP pipelines, and given how every HTTP system today uses the current syntax, I suspect mapped values that cannot be represented in the original syntax have to be treated as an error. Which means I think we need to go through the exercise of writing SF-to-text converters for each mapped field and then narrowing the allowed inputs until that converter is infallible.
It sounds like removing the field names is the best path forward. Yes, for those, the application using retrofit needs a fallback, just as it does for compatible fields. If that isn't obvious from the document, it should be clarified -- perhaps in a new 'Using Retrofit Fields' section.
I could very well be incorrect, but it sounds we want to have alternatives per each hop. Does that mean that these mappings would be best represented by ther per-hop pseudo headers that we have in H2 and H3? Not that I feel that doing so would be the best option, though.
Ooh yeah, per-hop is a good way to think about this! For pseudoheader vs. something else, I suspect it'll depend on use?
Code change:
mapped defines alternative representations of existing fields. Because downstream consumers might interpret the message differently based upon whether they recognise the alternative representation, <del> implementations are prohibited from generating such fields unless </del> <ins> implementations are prohibited from generating such values unless </ins> they have negotiated support for them with their peer.  This specification does not define such a mechanism, but any such definition needs to consider the implications of doing so carefully.

Related discussion:
text: draft-nottingham-binary-structured-headers already has a flag, so it probably could just use the original names, though pseudoheader names would work too I suppose. The existing names has the minor benefit of being able to reuse the existing HPACK static table. Some sort of SF-based HTTP API like probably (?) doesn't want pseudoheaders in the API and can just use the original names. But I haven't put much thought into that. If one wanted to send them in their textual form in existing frames, we probably need pseudoheaders. Though I don't know if we really get much value out of defining that, over just using the existing syntax. shrug We can also punt this problem to documents that want to use this, if we're not sure yet. :-)
If you want to use an invalid field name, there are a lot more options than putting a ":" in the first byte. You need to negotiate that usage, but then you can do anything at all, including using that to signal lots of stuff. (If you want to avoid the extra byte, you can pack data into the high bit of each byte...)
I feel like punting is the right solution, unless we can come up with a convention that addresses the identified issues in all cases.
Not acting is a decision of a sort. But I'm not sure what that would concretely mean for retrofit? No prefix? Or just that we shouldn't worry yet about the effect this has on smuggling through WAFs and whatnot?
I think it means: No new header names; applications that use mapped fields need to define their own way to distinguish them A new section about these considerations
Code change:
representation and the date is a strong validator in the sense defined by lastmod.comparison. <del> A server that evaluates an If-Range precondition MUST use the strong comparison function when comparing entity-tags (entity.tag.comparison) and MUST evaluate the condition as false if an </del> <ins> A server that receives an If-Range header field on a Range request MUST evaluate the condition as per evaluation prior to performing the method. </ins> <del> validator is provided that is not a strong validator in the sense defined by lastmod.comparison.  A valid </del> <ins> To evaluate a received If-Range header field containing an </ins> <del> can be distinguished from a valid </del> <ins> : </ins> <del> by examining the first three characters for a DQUOTE. </del> <ins> To evaluate a received If-Range header field containing an : </ins> <del> If the validator given in the If-Range header field matches the current validator for the selected representation of the target resource, then the server SHOULD process the </del> <ins> A recipient of an If-Range header field MUST ignore the </ins> <del> header field as requested.  If the validator does not match, the server MUST ignore the </del> <ins> header field if the If-Range condition evaluates to false. Otherwise, the recipient SHOULD process the </ins> <del> header field.  Note that this comparison by exact match, including when the validator is an </del> <ins> header field as requested. Note that the If-Range comparison by exact match, including when the validator is an </ins> , differs from the "earlier than or equal to" comparison used when evaluating an

Related discussion:
text: Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)
Code change:
The following content applies to the CWT protected header: <del> "16" TBD (type): REQUIRED.  The type of the CWT MUST be "statuslist+cwt" as defined in CWT.typ. </del> <ins> "16" (type): REQUIRED.  The type of the CWT MUST be "statuslist+cwt" as defined in RFC9596. </ins> The following content applies to the CWT Claims Set:

Related discussion:
text: Rendered Version: URL
COSE typ is now registered in IANA. Because of that, the TBD could be removed.
Code change:
The following content applies to the JWT Claims Set: <del> "iss": REQUIRED.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Status List Token.  In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within the Referenced Token. </del> <ins> "iss": REQUIRED when also present in the Referenced Token.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Status List Token.  In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within the Referenced Token. </ins> "sub": REQUIRED.  The "sub" (subject) claim MUST specify a unique string identifier for that Status List Token.  The value MUST be

Related discussion:
text: Fixes most of Relaxes requirements on referenced token in terminology issuer in status list token is only required when also present in referenced token (and matching checked) reorder references
Code change:
5.5. <del> This example uses the following object as the set of claims that the Issuer is issuing: </del> <ins> In this example, a simple SD-JWT is demonstrated. </ins> <del> The following non-normative example shows a payload of an SD-JWT for this End-User data: </del> <ins> The Issuer is using the following input claim set: </ins> The Issuer in this case made the following decisions: <del> The Issuer creates the following Disclosures: </del> <ins> The following payload is used for the SD-JWT: The following Disclosures are created by the Issuer: </ins> The payload is then signed by the Issuer to create a JWT like the following:

Related discussion:
text: update: agreed to replace SD-JWT VC example with PID. agreed to have only one sd-jwt vc example, so this will also address and
The and the editor's draft didn't get generated - URL 404s
fixed - thank you, Brian!
NAME Binding design and the usage of biometrics data is based on your original PR 210. Shall we replace 4a example with this one? But if you don’t see the need for this example anymore, I am not going to die on this hill.
Thinking about this just a little more NAME does this warrant a doc history bullet? Something like: Replaced the general SD-JWT VC example with one based on Person Identification Data (PID) from the European Digital Identity Wallet Architecture and Reference Framework The history is nice to have and I often use it as a starting place when making "what's changed from last time" type slides for f2f meetings.
I'm just gonna add the doc history to keep things moving here... and done w/ 08d70d2fbfcb1afce5e2d088cb97934b91ce83a1
relevant section in the editor's copy preview: URL should anyone want to take a look before the coming soon merge NAME NAME @ etc
I think this is ready to merge (for real this time). It's kinda awkward process and numbers wise with Dr. out. And peppelinux is still listed as requesting changes but I think his comments were addressed. But I think it's good to go. Approved with two pendings suggestioni/change request and a general comment that's not relevant for the revision but Just informative
Code change:
5.5. <del> This example uses the following object as the set of claims that the Issuer is issuing: </del> <ins> In this example, a simple SD-JWT is demonstrated. </ins> <del> The following non-normative example shows a payload of an SD-JWT for this End-User data: </del> <ins> The Issuer is using the following input claim set: </ins> The Issuer in this case made the following decisions: <del> The Issuer creates the following Disclosures: </del> <ins> The following payload is used for the SD-JWT: The following Disclosures are created by the Issuer: </ins> The payload is then signed by the Issuer to create a JWT like the following:

Related discussion:
text: replaces , addressing issue I also cleaned up example structure, so that it is the same and uses the same language across multiple examples.