jiebi/CodeConvo huggingface dataset:
… AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.
This removes the in-document "issues" list and background introduction note paragraph, in line with the document's status as a working group draft backed with an issue tracker. All removed items should have corresponding issues tagged with in this repository's issue tracker (some have already been closed), so keeping them in the document was redundant and artificially inflated the page count.
NAME good idea, note added to the top, following the pattern in other drafts
LGTM. You might want to add a note at the top directing folks to the issues list, etc.; see other drafts.
In 416 status code section, remove duplicate definition of what makes a range satisfiable and refer instead to each range unit's definition. In sections on bytes ranges and Range, clarify that a selected representation of zero length can only be satisfiable as a suffix range and that a server can still ignore Range for that case.
Regarding byte ranges, an empty (zero-length) representation is unsatisfiable according to section 2.1, but not unsatisfiable according to section 4.4 if the first-byte-pos is zero. I would like to see an update to the RFC which explicitly resolve this self-contradiction in whatever way seems appropriate. The following is one suggestion, but there may be others: I would like to suggest explicitly specifying that an empty 200 response should be returned in this case. It is the simplest solution to the current self-contradiction in the RFC, since it is a valid response anyway (if the server chooses to ignore the Range header), clients already handle it properly, it provides all necessary information about the representation to the client, and stating it explicitly can prevent subtle edge-case pitfalls in both the RFC and its implementations (as opposed to more intricate solutions). Perhaps the following can be added at the end of section 3.1: "If all of the preconditions are true and the target representation length is zero, the server SHOULD send a 200 (OK) response." (someone in the discussion preferred this to be a MUST, but the SHOULD might be more in line with the previous sections and backward-compatibility if some implementations resolved this in some other way.) I raised this in the mailing list a while back, and it got some discussion and support but did not get officially resolved. More recently I reported it as errata but it was rejected as not being an erratum and redirected here (I apologize - didn't realize issues moved to github, and still not sure what the distinction is :-) ), so here it is, raised again. All suggestions and feedback are welcome.
So how do we get this fixed? There was a discussion about it in the IETF mailing list, in which others confirmed the issue. I opened an errata, but it was closed saying it's not an errata. I was pointed here to open the issue, but got no response in 9 months so far. What can I do to get a response or to help move this forward?
If the powers that be don't agree that the issue requires fixing, it would be nice to get such feedback explicitly and discuss it. If this issue tracker is inactive and the issue should be posted somewhere else, I'd be happy to do it, just point me in the right direction.
We're not currently working on a revision to this document, so an official answer won't be forthcoming for a while. In the meantime, the best thing to do is to discuss it on list, taking the advice you get there. See Roy's response in particular: URL
Just looked this up to see if it's been forgotten... can I assume from the new labels that it's on someone's todo list and will be looked at eventually, even if it'll take a while longer? (btw the link your referenced actually contains another bug, so I'm referring to both, i.e. the whole discussion).
NAME Thanks for resolving the issues! Better late than never :-) Indeed now there is no longer a self-contradition in the spec, but I'm curious, why did you change your mind since the discussion in the link above, where you seemed to prefer a 200 result for an empty resource (even suggesting a MUST), to the current fix which leans towards the 416 by defining it explicitly as unsatisfiable (with the option 200 downgraded to MAY), or at best makes it a tossup which option servers will implement? Did you have any specific pros/cons or use cases in mind? I guess I still prefer a 200 as the simpler and more straightforward solution :-)
An implementation can choose to send 200. Making that a SHOULD or MUST would be a new normative requirement that isn't justifiable for interop.
ok. Thanks again!
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.
In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .
Makes "Parse a Number from Text" not be greedy, and return (not fail) when it encounters a non-digit character.
I'm pretty sure it works. Steps 5 & 6 ensure there's always at least one digit. All the calling contexts of "Parsing an Item from Text" (including the top-level algorithm in §4.2) inspect the next character, and handle it appropriately.
SGTM
Section 4.2.6 (Parsing a Number from Text) is ambiguous. It makes no mention of the exit condition from the while loop in step 7 on parsing a number from an input buffer.
I don't see it. The loop terminates with "fail parsing" in 7.4 (invalid character), or 7.5/7.6 (too many digits); or terminates successfully by virtue of "input_string is not empty" becoming untrue.
An example might clarify what I find ambiguous. Let us suppose that the input string is "-11-1, 4, 3", and that we are parsing a list. We'd call parseItem(), which would then invoke parseNumber(). When should parseNumber() stop reading in characters? Should it read in "-11" and then leave the rest to the next parsing function, or should it read in "-11-1" and then fail parsing? The other sections are unambiguous as to when to stop reading in characters (for instance, section 4.2.7 step 4.3 states that parsing of a string would stop when you encounter a DQUOTE, and section 4.2.9 step 3 states that parsing of binary content would stop when you encounter an ending asterisk).
Oh I see what you're saying. Yes, step 7.4 shouldn't be so aggressive.
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).
The role somewhat limited what actions were valid, but it's not clear that was important. Also, some things can be limited by MAXSUBSCRIBEID now.
I understand that a ClientSetup is sent that includes the role of if the client only wants to send objects, the role of if it only wants to receive objects, and the role of if it wants to both send and receive objects. And I believe that basically only the following relationships can be established: Client: vs Server: Client: vs Server: Client: vs Server: My questions are as follows: If a ClientSetup with or role parameters were to arrive at an ingestion-only server, how would the server handle it? Is it required that the server returns that the client does not expect and the client understands the server's intention? If a client that has already sent or receives a ServerSetup containing , is it acceptable to use that connection as is? There may be some security risks in this case. Thank you!
As a side note, if the conclusion in will be that Role Parameter is unnecessary or no consideration are required as endpoint behavior, then this issue would be unnecessary.
Not clear what the use case is. Seems like a foot gun in that it can be set wrong for how the connection is used.
I don't care if we leave it or keep it. Just adding this as I got questions about why have it.
Having the client voluntarily declare itself to abide by a certain role is not preventing the relay form having to do any work. A malicious client will declare one role but then act differently. Any relay open to the public has to protect itself against unauthorized ANNOUNCE and SUBSCRIBE control messages, irrespective of what role was declared. Therefore the upfront role declaration is superfluous.
I tend to agree it's not doing anything helpful here, and sent out to remove it.
Only suggestion to adjust other setup parameter keys now that you have removed 0x00. Given we don't have a strong need for this, glad to see it go for now and we can add back later if we find a strong need for it.
Adds a new "Content-Dictionary" with the hash of the dictionary used when encoding the HTTP response. For
NAME this adds the dictionary hash to the HTTP response when used. Right now it is a . Let me know if you think it should be a instead.
Mostly for developer ergonomics to make it easier to deploy. In the case of static resources using previous versions as dictionaries (v1 to v2 of URL), one method for enabling that is to compress the new version using the old version on the cli as part of the push to production and store the dictionary-compressed artifact as a file on the server next to the full file. Then at serving time, compare the value of the request header with the file names on the server for the given URL to see if a delta-compressed artifact is available. Structured fields encode the binary data as base-64 encoded strings which aren't filesystem-friendly so there would need to be some steps at serving time to decode the header, convert it to ascii and then check. It's not insurmountable but it's a bit more processing and a straight string match could be handled directly with templating in server config. Lowercase hex was picked since that's what all of the cli tools for generating hashes emit.
Is a reasonable name for the response header? I'd actually prefer but it felt like that might be over-stepping since there could be some other generic need for associating a dictionary with a HTTP-response but maybe I'm being overly-cautious.
I don't think that authoring convenience outweighs the advantages of having a unified grammar here. It's not like base64 is some esoteric function. If you are talking about sha256sum, here's a toy: URL
I agree with NAME - don't. To make the sf value filesystem friendly, you just need to strip a few characters and remap "/".
Keep in mind that hashes are not hex strings. A SHA-256 hash is 32 bytes of binary data. The hex thing is just what some tools happen to output. But anything consuming this programmatically to, e.g., compare the hash against something would be best served by the underlying bytes. Using base64 is also slightly more compact on the wire. And if binary structured fields gets off the ground, it can be even more compact.
My main concern is trading off a unified grammer of using sf-binary in the headers vs consistency with tooling and how the dictionaries are represented once it gets out of the protocol. In the dynamic case, this could be something like the web server checking to see if the requested dictionary is available (on disk) in response to a request. I don't know how each web server will choose to build that but having files named with the hash is an easy common starting point. Otherwise each chooses what the ascii representation of the 32-byte hash should be for their case. On the static case, I'm not so much worried about not having a tool that can create base64-encoded strings of sha256 hashes (it's trivial as you pointed out). I'm more concerned about the transformations that need to happen at serving time to decode the hash, convert it into an ascii representation and then check if that variant of the encoded file is available. It's certainly all doable, but it requires base64decode and binhex (or some equivalents) to be available in the layer where the checks are being done - or to rely on application code. Specifically, I was thinking that it would be easy enough in VCL or an existing Nginx or Apache config to do something like: If request header is present and validates against a [0-9a-f]+ regex and 'br-d' is available in the request header try returning + '.' + request['Accept-Encoding'] + '.br-d' (and add relevant response headers) otherwise return Doing similar processing with base64-encoded hashes has a step to convert it into an unspecified format that is platform-specific and may not be doable without either running application code or updating the server with base64decode + binhex support. It likely doesn't matter for the case of applications and servers that are dictionary-aware and can operate on the raw hashes (and enjoy the ~20 byte request header savings) but it is a tradeoff that pushes complexity further up the stack so I just want to make sure that is the tradeoff that we want to make.
Having a finally consistent grammar for HTTP is the precursor to get consistent tooling. It may be more convenient to do something else in the short term, but in the long term we'd just be adding to the mess of inconsistency in HTTP.
In the long term, I would hope that these config language DSLs would be able to process structured fields natively. (Although, it may be on this WG to demonstrate this being possible, since the data model for structured fields is slightly interesting...) I also don't think we should be encouraging, much less designing for, folks trying to process HTTP headers with regexps. There's a well-defined grammar and inventing other parsers is a great way to not quite get things right. We already have a pretty hard time with HTTP extensibility due to folks parsing it wrong. The path-unfriendliness is a little unfortunate. Possibly we should have picked the URL-safe version of base64, but too late for that. But since byte strings and text strings aren't the same type, I imagine any sf-binary-aware config language DSL would also have hex and base64 functions available. Indeed taking attacker-supplied input and mapping it to a path component, without running it through some very restrictive encoding, seems a pretty bad idea! At the end of the day, SHA-256 hashes are byte strings, and sf-binary is the way HTTP decided to say byte string. We could say that, although SHA-256 hashes are byte strings, dictionary names are ASCII strings computed by hex(sha256). Then these headers should be sf-string (with quotes). But that would be less efficient on the wire, and our on the web is to put user needs (bandwidth, in this case) first, so I think this is the wrong tradeoff. That said, I see also uses this format. It wouldn't make sense for and to use different formats, so perhaps switching away from the less consistent and less efficient format should probably be handled separately from this PR?
I switched and both to sf-binary. The plan is to update the ID and then send out a summary of changes for discussion on the listserv and since this PR is about the dictionary in the headers anyway it should be fine to update both of them at the same time. Happy to split it out if it helps with history tracking.
I think this change adds significant complexity, and I'm not sure regarding its benefits.
I very recently played around with prototyping a compression dictionaries deployment and was very happy with the simplicity of it: You generate diff files at build time with some naming convention Then at serving time, you configure your routing logic (similarly to how NAME ) to those diffs That can be done today in almost any deployed routing layer. Once this change lands in implementations, a similar deployment would require me to add custom logic to transform that header value to something that is file system friendly. It doesn't matter if that transformation is to base64 decode the binary data and then to hex encode it, or to 'just.. strip a few characters and remap "/"'. It is an operation that is not necessarily supported in many layers that developers currently operate in. To take just one example - if I were to implement this as a , I'm not even sure it's feasible to do that. (although it might be, with a creative ). Can you elaborate on the advantages of moving to base64, beyond theoretical purity?
I don't understand how a client determines which dictionary was used by the server. It seems like the response depends on the request, which is fragile (and doesn't allow clients to advertise multiple dictionaries, which seems likely with Use-As-Dictionary as it is). cc NAME Moved from private ID
For identifying the dictionary, it's worth noting that the spec requires that the client advertise a SINGLE dictionary that it supports but yes, the response depends on the dictionary identified in the request. This also helps with minimizing the variants that caches would need to store since the response needs to be varied on the request's available dictionary (and multiple would explode the permutations). It wouldn't hurt to echo the dictionary hash in the response which would allow for other mechanisms of advertising dictionaries but that also carries the cost of complicating the vary logic (would need to vary based on whatever request header was used to negotiate the dictionary that ended up being used).
Dictionary hash used is now in the response headers.
If this field carries binary data, why aren't you using structured fields?
Resolves URL
cc NAME NAME
Hey Yoav, Thanks; will take a look. Two immediate things: You're getting a error in the markdown; . I see you've added yourself as an author. That's generally the decision of the chair - NAME in this case.
Hopefully fixed. Is there a way to test it locally? Apologies for the noobness. Removed myself.
See URL for build info.
NAME Thank you for working on the proposal. Am I correct in assuming that changes other than the switch to Cuckoo filters and the introduction are unintentional? For example, I see flag of the frame being removed. Do you have a working code that implements Cuckoo filters? I am curious to see it working. The concept of makes sense to me. Maybe we might want to adjust the codepoints and the naming in relation to .
Oh, I now understand the intent of removing the flag. The motive of the proposal is to build a digest without referring to every response object stored in cache. The fact means that it is not be easy for the client to determine the freshness of the entries that is going to be included in the digest. I am sympathetic to the idea, but I am afraid if the approach works well with the current mechanism of HTTP/2 caching. My understanding is that browsers that exist today only consume a pushed response when it fails to find a freshly cached response in its cache. Otherwise, the pushed response never lands in the browser cache. Unless we change the behavior of the browsers to respect the pushed response even if a freshly cached object already exists in its cache, there's a chance that servers would continually push responses that gets ignored by the client (due to the existence of a freshly cached response in the browser cache with the same URL). NAME Assuming that I correctly understand the motive of removing the distinction between a fresh digest and a stale digest, I would appreciate it if you could clarify your ideas on the problem.
Thanks for reviewing, NAME :) My intent was to include all stored resources in the digest, regardless of them being stale or fresh. Entries are added to the digest when a resource is added to the cache and removed from the digest when a resource is removed.