jiebi/CodeConvo huggingface dataset:
Implementing Date in Python as a object has an issue -- Python dates are limited to a specific range. Given that it's good to expose SF as idiomatic data structures wherever possible, I poked around a bit for limits on date/time objects in libraries, and found (all expressed as limits on years, as that's the most significant bit): Python - Rust - Go - PHP - JavaScript - Ruby - Java - Should we specify a minimum range of dates that an implementation should support (likely 1-9999) so that developers can be confident of them (as we've done for other data types)?
Hm. Do these differences affect other parts of HTTP as well, such as processing the "Date" field (or fields specific to caching...?).
One would imagine that people put HTTP dates into these structures from time to time, yes.
(it's just that HTTP dates rarely go outside the range 1970 - "forseeable future")
Restricting to a year-based range would IMHO make sense if we actually would be using calendar dates (which we do not).
To be clear, I'm not proposing we restrict it -- just require implementations to support at least a particular range of values, just as we do with many other types. Don't get stuck on years, that's just a rough sizing to get an idea of what we're looking at. I think we'd express it in integer values.
I've commented in the PR that I dont like this, but let me add a bit of context: Handling of time, in real life and in computers, is incredibly messy and one of the most unreadable scientific books of all time is "Calendrical Calculations" which is our best shot at that subject matter. I really do not want us to wade into this tarpit, because everybody who has ever done so, has just added more tar in the process. My really strong preference is if Date was defined as "Seconds since Epoch" according to POSIX" with the full range of signed 15 decimal digits we inherit from Integer, so that we in no way adds any further complexity.
That's effectively what we have, even with this addition. This text is just requiring implementations to support at least a certain range, so that it can be relied upon for interoperability.
Section 1.1 is currently a bit confusing, because it leaves out sections, and does not present them in order (likely the cause of a recent re-org).
NAME do we need it?
it should either make sense, or should be removed.
NAME if it's not required, I think that the document is fine without.
mnot asked us to add one a while back, which I think helped at that point. Editorial changes in the meantime have had an effect though, so I tried to add some colour to the structure in URL Preview at URL The intention is that people can launch of from here to focus on bits they might need, like the field definitions or example. Since security and IANA sections are standard, mentioning them seems superfluous. If the opinion is that the proposal doesn't help, let's just remove the section.
… in that the request must be understood in order to parse and interpret the response.
Well, the simple version is a normative statement in sheep's clothing. Let's just make it normative.
Section 6 claims that . It uses the word "intended", which is an intention that is broadly achieved, with only one exception that I'm aware of at the syntactic level. Having recently implemented message/http, I discovered that some response messages cannot be processed without knowledge of the corresponding request. This is pretty annoying and might be worth noting as a possible exception here. As noted in the response to a HEAD request might include Content-Length, but the content of the response is always empty. At a semantic level, I don't think that any response can be considered without knowledge of the request, so I don't think that self-descriptiveness can possibly apply there. Besides, this section is clearly intended to provide an abstract definition of the syntax and not semantics.
See also
Allow the original name of the next hop to be the start of the list, and add an example.
NAME NAME please review!
LGTM
I understand that the current draft is specifically targeting forward proxies, but as currently described, the is missing some information when used by reverse proxies, and it's not self-contained anymore (i.e. the requested/configured next hop is not part of the field), making debugging much harder. I find the fact that is not included here a bit confusing. While operators or clients connecting directly to might know that it's a forward proxy and could infer that was the requested hostname, the clients that are a few hops away from it, won't know this, and might be surprised how the and other aliases got in there. Furthermore, in a similar scenario with a client connecting to the reverse proxy and requesting , which is configured to use as the backend, that response is missing the most critical piece of information, and instead of helping, it adds more confusion. As such, I'd suggest that the requested/configured hostname should be included as the first entry in , especially when points to the resolved IP address. cc NAME NAME
This is a good point, especially for reverse proxies. The name of the next hop could be in the next-hop parameter itself, but then there is a choice between the address and the name there. For forward proxies, the name is known and the address is interesting. For reverse proxies, i imagine the name of the next hop is more useful than the address, but I can see why both could be wanted. In such case, perhaps we can allow the aliases list to include the next hop name if it differs from the authority requested by the client.
Yes, that's unfortunate. I'm not sure how we've missed this in RFC 9209. Perhaps we could allow both and use for the configured next hop name, and for the resolved IP address... which actually matches what I'm suggesting we do here by including the requested/configured name as the first entry in . But that's only true on the first hop, right? The authority could be changed along the way by intermediaries, and then the original client wouldn't know what started the resolution which resulted in the received . How would the original client know if that happened in a long chain of proxies?
The authority requested by the client connecting to is not included in the header, and therefore it's not known to the original client. It's impossible to tell if that entry was generated by a proxy that was configured to connect to , which also happens to be the authority it received and therefore it's not included in , or if it was configured to connect to . Basically, I'm trying to avoid adding ambiguity and guesswork to the debugging process that uses this header.
Upon discussing in person: Good to add to an example The text should make it clear that the original name is allowed to be at the start of the list (but doesn't strictly need to be included)
Regarding the case of multi-valued header, we have this: I'm not seeing anything there which forbids the use of "Content-length: 5,10" anymore. I'd rather emphasize the need for extremely strict parsing of Content-length and keep the duplicate case as the only acceptable exception to this rule, approximately like this: "The Content-Length header field plays a crucial role in message delimitation in HTTP/1.1, and a different error handling between agents was shown to have important consequences in terms of security. As such, it is extremely important that agents do not accept Content-Length header field values that do not strictly comply with the ABNF, that they take care of rejecting values that they are not able to accurately represent internally, and that multiple occurrences of the header field are always checked for, and rejected as invalid. As an exception, if the header field is received multiple times with the same value, or is received as a comma-separated list of identical values, the recipient MAY replace all of them with a single valid Content-Length field containing that decimal value instead of rejecting the message."
Messaging 6.3 says: I think that covers it for HTTP/1.1 (if Transfer-Encoding and Content-Length are both present, that's encouraged to be handled like an error). HTTP/2 says: HTTP/3 says: ... so we could say something in semantics about invalid content-length fields when it's not being used for delimitation, if we wanted to.
Hmmm interesting. I haven't read enough of both parts yet but it's not that bad because I'm in the same situation as someone seeking a solution. I think in the semantics part, there should be an explicit reference to the messaging, for example, "Certain versions of HTTP use Content-Length for message delimitation and may impose stricter rules". This could be sufficient to make the reader check the respective messaging parts. What about the point about being careful about internal representation (i.e. no overflow nor loss of resolution) ? I know I placed it in the middle of the text because it flowed naturally, but this remains a valid item as well.
As a general rule, I think we should not add text to semantics that says some other document has a requirement unless that specifically enlightens the reader regarding the meaning of that protocol element. This is important because the Semantics spec is already "too long" for easy review. If the requirement matters, it will be read by readers of that other document.
NAME see revision.
The language for and indicates that they override the rest of the caching model unconditionally; as discussed in , that is too broad. Also, is often used even though the message is still cacheable, because developers misunderstand its semantics.
The text in question for private: to any other cache directives present, even if the response would not otherwise be heuristically cacheable by a private cache. lists one or more field names, then only the listed fields are limited to a single user: a shared cache [...] &MAY; store the remainder of the response message without those fields. I think there are two problems here: 1) "subject to any other cache directives present" is too narrow; the requirements in 3. Storing Responses in Caches go far beyond cache directives (e.g., method and status code cache ability). 2) The second paragraph omits any such condition. I think this can be addressed by replacing the clause above with something like "subject to the other requirements in [ref to section 3]", and repeating it in the second paragraph. We'd also need to add to the list in section 3 (probably below .
For public, we have: response even if it would otherwise be prohibited, subject to the constraints of any other response directives present. In other words, public explicitly marks the response as cacheable. Similar to above, I think it should be "subject to the constraints defined in [ref to section 3]. A note like this would also help:
LGTM.
This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,
Please correct me if I'm wrong, but IIUC, the crux of this PR is that to allow any client that can present a valid pair of Authorization and Signature-Auth-Context header fields to obtain a protected resource. Assuming that if we would be allowing such behavior, I wonder why we need to require clients to export keys from TLS session, rather than just coming up with some arbitrary authentication context and present it to the server? Or if it is the case that there are situations in which we have to require clients to use keys exported from TLS session, doesn't it mean that there are cases where servers must ignore Signature-Authentication-Context header field or drop it?
NAME no this is only for trusted intermediaries. If a server receives a Signature-Auth-Context header from an untrusted source then it drops it. That's somewhat mentioned on line 470, but I'll add normative text.
More explicitly state that SD-JWTs have to be signed asymmetrically (no MAC and no ) One item out of John Mattsson's review: URL Thanks for the review John. I've tried to reply to the comments inline below. MUST be signed using the Issuer's private key" in sec 5.2 .) but I think you're right that it should be explicit. I assume it would be a claim. Is there something that suggests otherwise to you? That "HOLDER-PUBLIC-KEY" only shows up in section 4.3 , which is supposed to be a somewhat abstract discussion about it. And I think it's separate from SD-CLAIMS and NON-SD-CLAIMS there to call attention to it. But not to suggest that it's not a claim. More generally (as sec 5.2.3. Holder Public Key Claim tries to describe) the specific way that holder public key binding is established by the issuer and represented in the JWT is out of scope. A "cnf" claim is used in examples for what it's worth. But the specific details of a holder public key binding claim are left to applications using or profiling SD-JWT. the hash input so as to make it infeasible to "reverse" the hash value by enumerating potential claim name/values into the hash function. Correspondingly a salt value is included in the disclosure structure directly alongside a claim name and value. I think using the word secret to talk about salt values would be problematic and potentially confusing. The salt values of undisclosed claims need to be hidden from parties to whom the claim isn't being disclosed. But the salts are sent from the issuer to the holder. And salts of disclosed claims are sent from the holder to the verifier. That's different from a typical secret (as I think of a secret anyway). We can look to add text or clarify text about not revealing salt values to unintended parties. that the "Issuer MUST ensure that a new salt value is chosen for each claim" and a "new salt MUST be chosen for each claim" in section 8.4 . I think that's what you mean by salts being independent of each other? Sec 8.5 has a 128-bit minimum length as RECOMMENDED.
As I recall, there was some desire to allow for shorter salts when used with a more computationally expensive digest function and the RECOMMENDED would allow for that situation by basically saying to use at least 128 unless you have a good reason to do otherwise and understand the implications. I think "key" or "secret" are definitely not the right name and would be more prone to mislead or confuse. It's a random value that's included in the hash input (that otherwise has a more predictable value space) to make it infeasible to guess/confirm the claim name and value from the hash value. And ensure that the hash output will vary when hashing the same claim name/value more than once. disclosure structure (containing the claim name & value as well as the salt) is hashed and the digest value is placed in the "sd" claim of the signed JWT. Each (signed via inclusion in the JWT) digest value is an integrity check on, and reference to, the corresponding disclosure. Length extension attacks aren't applicable to this kind of use of the hash value. Any change to the disclosure content breaks the integrity check and any change to the hash value breaks the signature. Cheers, CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
The current section on CONNECT (7.3.6) in the semantics document refers to the proxy forwarding packets: Since the proxy terminates TCP, there is no forwarding of IP packets, but rather the contents of the TCP streams.
Well spotted! I'd even suggest "to blindly forward bytes in both directions ...". Too often I see people who imagine that packet delimitation is respected on both sides of a proxy and I have to tell them that it's just a uninterrupted stream of bytes that each layer decides to delimit wherever it wants.
I'd say that 7231 is self-consistent with the use of packet in 7230. If a change is needed, we should change wording consistently. Or, was this issue raised on the WIP core doc?
NAME this issue is being raised on the WIP core doc. The same text does also exist in 7231, but I consider them to both be in error. While we're updating the text for the core doc, let's fix the text to be clearer.
Thanks for the clarification NAME that sounds good to me.
Fwiw, the HiNT draft uses the terminology: blind forwarding of IP payloads, UDP datagram payloads and TCP/IP packet payload.
HTTP/3 says:
NAME that text looks good. Something along those lines, but that also works for HTTP/1.1, would be right for this core doc text.
Maybe just replace "packets" with "data"?
So as mentioned above in , while having a look at the latest draft I was struck again by this "packets" there, and even forgot about this old issue. Pinging again. I suggest that we change "forwarding of packets" with "forwarding of the byte stream" so that we can close these issues.
In , Orie commented that: The answer is obviously "no", but the fact that the question was raised seems to indicate that the reference to 9338 is potentially confusing. Note that if we removed it, nothing would change, which is an incentive to drop. Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >
add registration policy cc: NAME and NAME to URL Using RFC policy avoids the issues we had to face to refresh the current table. See
NAME now it's Specification Required :)
This specification obsoletes 3230 and updates the IANA registry to point to it, but doesn't specify what the registration policy actually is.
Related to NAME says
See
NAME do we need ? [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. Also, these might be better placed in IANA Considerations.[x] 5. There should not be RFC2219-MUSTs in IANA registry text. This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."[ ] 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there.
I'm sure I made this comment somewhere but I've lost it. I don't think we should mandate RFC required, that a very high bar for algorithms (and their users) that most likely developed the algoithm elsewhere already. Instead seem like a better option here
NAME imho registering new algos should be done via an RFC, this doesn't imply that those algorithms should be defined in an RFC. While it is fair to delegate the registration to an external specification, I think the approach of an RFC (eg URL ) is a lot more clean and improves the overall interoperability. It is important to note that any type of RFC is sufficient (currently Standards Track, BCP, Informational, Experimental, or Historic). In any case, I don't think this should be a game-stopper, so if there's general consensus on "Specification Required", that's ok.
I don't think running an RFC process can provide any meaningful value to the registration requirements. I mean, that's going to add like a year of overhead to something as simple as "use algorithm $foo with token , the output is encoded using base64".
The key to Specification Required is the Designated Experts. If they do they job you basically get what you need.
This change makes it explicit that the content encoding is (same as ) and is (same as ). See the discussion in for why larger ZStandard values were not selected. This carries some nuance for what encoding to use when compressing for maximum benefit as the resource size crosses beyond 8 MB but that is more of an editorial discussion about the individual compression algorithms and probably better laid out in blog posts or explainers than in the spec.
NAME could you PTAL and make sure the language matches what you're working on for the update?
Thanks. I switched the content-encodings definitions and IANA registrations to a list with references back to the algorithm RFCs. For the IANA registrations I removed the window size from the text and linked it to this document (where the window sizes are defined) instead of to the compression algorithms directly. Let me know if a more verbose description of the need to specify the window sizes would be useful or if just being explicit about what they are is enough.
Context: URL aims to clarify the window size limit for the Content Encoding token as it wasn't clear in RFC8878. Since the Compression Dictionary Transport draft hasn't been published yet, we should also add some window size considerations to it for and to maintain interoperability. I think in Chrome we ended up using . NAME
NAME could you comment on how this impacts Brotli dictionary decode? Is the dictionary independent from the compression window (so we can adopt the same defaults as or do we need to specify something relative to the size of the dictionary? NAME NAME for ZStandard, to allow for delta-encoding large resources, is reasonable or should it be ? We have use cases for delta-encoding wasm applications where the dictionary can easily be upwards of 50 MB.
For Zstandard, the states that the entirety of the dictionary is accessible as long as the input is <= Window Size. Therefore, to give an extreme case, it's possible to have a 50 MB dictionary, and it's entirely accessible even if the Window Size is only 1 KB, but only as long as the data to de/compress is <= 1 KB. As soon as we reach 1 KB + 1, reaching the dictionary is no longer valid. For delta compression, this has consequences.