jiebi/CodeConvo huggingface dataset:
Code change:
Therefore, authors are advised to delimit or encode values that contain commas (e.g., with the <del> rule of quoted.strings, the String data type of RFC8941), or a field- </del> <ins> rule of quoted.strings, the String data type of RFC8941, or a field- </ins> specific encoding).  This ensures that commas within field data are not confused with the commas that delimit a list value.

Related discussion:
text: FP: what does it mean for a header field specific value to be not-interoperable? I am also not sure how "*" between the list of values would be processed. 2. above does not specify it, only stating: If the field value is a list of entity-tags, the condition is false if one of the listed tags matches the entity-tag of the selected representation. FP: I would possibly interpret this as "search for tags matching the entity tag - ignore all others". Editors: URL and URL [x] 19. ----- senders might send erroneously send multiple values, and both FP: remove one "send". Editors: URL [x] 20. ----- the String data type of [RFC8941]), or a field-specific encoding). FP: remove the first parenthesis. Editors: URL [x] 21. ----- FP: This is more of a check, but I see that all references only point to sections. I hope this will be translated into "x.x.x of RFCthis", is that correct? Editors: URL
You mean in the tables for IANA registrations? That's for brevity; IANA knows how to deal with that.
The media type registry is not owned by "us". I don't think we have the authority to change it.
I will look into this with IANA and the DEs and get back. Just to be clear, the document states "future media types are discouraged..." but what we really mean is "experts should be conservative with assigning ..." , is that accurate? Yes, in theory we'd like to discourage media types to be registering "q", but the practical way to make sure that doesn't happen is to make the DEs react to it if it does.
maybe "...whenreferring to that protocol version..."? NAME ?
Yes, thanks!
I don't think it's restricted to that.
For instance, to provide a bookmark/make something accessable for a subsequent GET... NAME - do you want to add that?
I don't get that question. The spec allows collapsing. It doesn't require it. Could you please clarify your question?
The motivation is that if something is defined as "safe", I can URL do that operation without being held accountable.
Code change:
Therefore, authors are advised to delimit or encode values that contain commas (e.g., with the <del> rule of quoted.strings, the String data type of RFC8941), or a field- </del> <ins> rule of quoted.strings, the String data type of RFC8941, or a field- </ins> specific encoding).  This ensures that commas within field data are not confused with the commas that delimit a list value.

Related discussion:
text: For instance, I can always GET a URI (such as for prefetch/preload/indexing) and if the server does do something stupid with that request (such as deleting a resource, or adding something to a shopping basked), it's their problem. Re idempotenty: this makes it possible to repeat a request.
The text states that intermediaries are allowed to collapse "an ordered subsequence of Via header field list members into a single member", and they can only do so "if the entries have identical received-protocol values." So I read 2 rules: the order matter, i.e. if (A,B) collapses to C, (B,A) does not map to C (A,B) must have identical recived-protocol values I was wondering about any additional rules that the intermediaries have to follow in order to collapse the list into one: for example, is it ever expected for the intermediary to remember that this single member was this collapsed ordered sequence? Are they ever requested to un-collapse?
Order matters for the purpose of collapsing. If you have "D, E, F", and E has a different protcol than D or F, you can't collapse. If "A, B" can be collapsed, so can "B, A" (because they have the same protocol) We are not saying that, so there is no expectation that the collapsing can be undone.
Ok, so yes I understand - the idea of this text is to say: "this is the intent, BUT be aware that implementations might do something stupid and not comply with this intent." I guess what I got stuck with was "the client can't be held accountable", as it wasn't clear to me what would it mean for a client to be held accountable, as clients in general are not aware of what's the action on the server their request will result in.
This might require a separate issue. A field value containing more than one list element and including "*" is invalid, and the spec really doesn't say what that means. The intent of saying "interoperable" is (IMHO) to prevent people from assuming the different servers will do the same thing with it. I believe we should clarify that a value like that is invalid, and thust MUST NOT be sent. NAME , NAME ?
That refers to URL - I guess we should cite that? NAME ?
Code change:
Therefore, authors are advised to delimit or encode values that contain commas (e.g., with the <del> rule of quoted.strings, the String data type of RFC8941), or a field- </del> <ins> rule of quoted.strings, the String data type of RFC8941, or a field- </ins> specific encoding).  This ensures that commas within field data are not confused with the commas that delimit a list value.

Related discussion:
text: Edit: opened URL
On the other hand, people complain about the spec being too long already. I don't think we should add examples unless they are needed to make things easier to understand.
Ok! (As I said, these are so minor that they are definitely up to you. Same with references and terminology comments)
I believe the simplest possible fix would be to remove "to be used in references", making this: NAME ? Edit: -> URL
I think that we should probably convert this one (and similar) to MUST NOT -- there isn't any situation where we recommend this behaviour, as it has interoperability and security implications.
Not convinced at all. The "SHOULD NOT" requirement is new and was controversial already. There is code out there using GET with body (in controlled environments) which just works.
That's not HTTP; that's a private protocol.
Tell that Google :-) Anyway. This is a normative requierement and we are past WG LC. If you want to change it, this absolutely needs to be confirmed explicitly by the WG (and would deserve a seaparate issue).
Maybe "The process for determining whether access is granted is defined..."? Edit: -> URL
You mean generally, for the fields we define? I don't think that's true; they're defined for the semantics they specify. If a use isn't specified, it might be extended in the future, so we rarely prohibit such a use. Saying that they can be used with any method or status code would imply that they have meaning in each circumstance, and that's often not true.
authentication. This isn't important for interoperability, it's just a bad idea. Maybe 'The From header field is not intended or suitable for use as a means of access control or authentication.'?
FWIW, the requirement is from RFC 7231, and widely accepted (I guess), so I don't think we should change it.
For 4, proposed rewrite:
WRT -- I don't think I'd use the word "widely" in conjunction with this header field. Again, if we use SHOULD NOT, we should explain the qualification.
In the sense that it's an interoperability requirement on a sender (not a recipient), I agree.
"MUST NOT be generated" maybe?
MUST NOT be generated, because recipient behaviour is not interoperable.
Code change:
Therefore, authors are advised to delimit or encode values that contain commas (e.g., with the <del> rule of quoted.strings, the String data type of RFC8941), or a field- </del> <ins> rule of quoted.strings, the String data type of RFC8941, or a field- </ins> specific encoding).  This ensures that commas within field data are not confused with the commas that delimit a list value.

Related discussion:
text: URL already say "MUST NOT generate ABNF-invalid messages" in general. So maybe we don't want to repeat BCP14 terms here... -> URL
I've reviewed the most recent commits, think this can be closed now.
Thanks for addressing my comments. I checked the commits and your answers: I can see everything was addressed, either by changes or by answers clarifying what I found confusing, except for: the one which is now issue point 14: giving context around the "SHOULD NOT" for the 'From' header field. Note that I am not asking you to make any change (such as removing the BCP 14 text), but following what BCP 14 defines: it seems important that the reader understands, or at least gets a hint of what these reasons and particular circumstances are, in order to be able to understand the full implications. This is why I think it's important to clarify the context around the SHOULD / SHOULD NOT, and was also my comment for the GET requirement, but I see that that comment has now transformed in a bigger issue the wg needs to find consensus on.
I disagree. You are presuming that we know those particular circumstances, and that is almost always false when SHOULD is being used. When we have a detailed list of conditions, we use "MUST NOT unless ...". The SHOULD is literally saying that the reader needs to take care and understand the risk/benefit for their own context, not that we need to explain to them based on our own imagination. It is fine to suggest additional text to address a specific concern, but I personally think that this one is self-explanatory. If we added a general description about why auth parameters shouldn't be sent in fields that are not expected to be treated as auth parameters by every recipient, such as within a security consideration, then we could reference it here.
I don't think we should know all possible circumstances, but I presume we do have an inkling that implementations going against the RECOMMENDations exist, for whatever reason, right? As a reader, putting myself in a new implementer shoes, I personally would have found it useful to get that hint of what to consider, but if you think that this one is self-explanatory, I won't insist.
Code change:
Therefore, authors are advised to delimit or encode values that contain commas (e.g., with the <del> rule of quoted.strings, the String data type of RFC8941), or a field- </del> <ins> rule of quoted.strings, the String data type of RFC8941, or a field- </ins> specific encoding).  This ensures that commas within field data are not confused with the commas that delimit a list value.

Related discussion:
text: The type of sentence I was thinking about would be something like: (Just trying to explain myself here, again, feel free not to take this suggestion if you and the wg don't think it helps the reader)
Okay, I have added URL because I think we should explain it if it isn't obvious to others.
Thank you NAME !
Code change:
shown in ex-bini-request.  As the content of this message is empty, the difference in formats is negligible. <del> This indefinite-length encoding can be truncated by two bytes in the same way. </del> <ins> This indefinite-length encoding contains 10 bytes of padding.  As two additional bytes can be truncated in the same way as the known-length example, anything up to 12 bytes can be removed from this message without affecting its meaning. </ins> 5.2.

Related discussion:
text: This adds the ability to pad messages to the binary HTTP format. The design is pretty simple: add zero-valued bytes to the end.
What if someone adds a non-zero byte in the padding block?
Code change:
The Expires attribute is mapped to a Date representation of parsed- cookie-date (see COOKIES). <del> For example, these unstructured fields: </del> <ins> For example, this Set-Cookie field: </ins> <del> can be mapped into: </del> <ins> would have a mapped value of: And this Cookie field: would have a mapped value of: </ins> 4.

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:
The Expires attribute is mapped to a Date representation of parsed- cookie-date (see COOKIES). <del> For example, these unstructured fields: </del> <ins> For example, this Set-Cookie field: </ins> <del> can be mapped into: </del> <ins> would have a mapped value of: And this Cookie field: would have a mapped value of: </ins> 4.

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:
The Expires attribute is mapped to a Date representation of parsed- cookie-date (see COOKIES). <del> For example, these unstructured fields: </del> <ins> For example, this Set-Cookie field: </ins> <del> can be mapped into: </del> <ins> would have a mapped value of: And this Cookie field: would have a mapped value of: </ins> 4.

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:
The Expires attribute is mapped to a Date representation of parsed- cookie-date (see COOKIES). <del> For example, these unstructured fields: </del> <ins> For example, this Set-Cookie field: </ins> <del> can be mapped into: </del> <ins> would have a mapped value of: And this Cookie field: would have a mapped value of: </ins> 4.

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:
The Expires attribute is mapped to a Date representation of parsed- cookie-date (see COOKIES). <del> For example, these unstructured fields: </del> <ins> For example, this Set-Cookie field: </ins> <del> can be mapped into: </del> <ins> would have a mapped value of: And this Cookie field: would have a mapped value of: </ins> 4.

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