jiebi/CodeConvo huggingface dataset:
This reverts commit 290e381719b2fefe4e6182d3be288c48e8f5fd7e. See for most of the discussion. The key change here is to address by only requiring that the change be signaled when the table size is reduced. When I dug more into this, it's a more disruptive change, so I've made a bunch of additional changes in support of that.
I have one suggestion about a point that seems to be possible to infer from all this but is not explicitly written and may condition the sequencing of operations. Do we want to support multiple settings updates on this parameter, hence announce in the middle of a communication that we changed our local decoder size ? It seems to me that this is the case but it does not appear in the original text where it more likely sounds like the initial size. If we want to support repeated size changes from the decoder, then I agree that it's better to consider that 4096 is initial and that the setting changes it and Kazuho's wording sounds fine. But then it possibly ought to be explicitly mentioned such as: This makes sure that it's safe for an encoder to only process the settings frame once and to send a single DTSU instead of one per SETTINGS frame.
NAME I struggled a little with your text, because I think that is what this already says. However, to address your question about settings changes, I don't think that we do really want multiple settings changes, but that is the protocol we have. So multiple settings changes are possible and implied by the design of SETTINGS. Multiple changes are possible within the same SETTINGS frame, in case you were interested. The designers of this protocol seemed to love unnecessary complexity. There are some good reasons, but it's not clear that those reasons are sufficiently strong to justify the headaches they cause. I would really like it if implementations could just signal once in the preface, handle the preface from their peer and be done with settings. That's how HTTP/3 works and while we might have been forced into it there by the complexities of the QUIC integration, it turned out to be a good outcome in my view. Here, however, we need to deal with the fact that the protocol permits changes.
Hi NAME I'll have to clone your repo and run the diff here by hand then because I can't figure in this horrible interface how to view the complete set of changes at once resulting from multiple subsequent changes. And it will be easier to reread Kazuho's proposal in context. Regarding "do we want" I didn't imply that we love this situation, just "do we want in order to support this interpretation of the protocol", given that the current text never explicitly states that (as Cory mentioned a while ago, the settings change is acked by a the settings ack) and that even the protocol's original co-author back then already stated that it wasn't meant to be interpreted that way ( URL ). Sure, the result is that we have what we have and we have to deal with it in the best way possible. In that spirit I think that Kazuho's proposal tries to be as closed as possible to the current state of deployment by indicating how some implementations behave vs what others expect and suggesting not to play in the gray area there.
Hervé's post there is quite useful, yes. That supports this overall view. I've cleaned up the comments on the diff view; let me know if what you see works. The diff overall is fairly clean (it's mostly additions).
I'm just a bit confused, where am I supposed to see the unified diff ? the only way I know is by clicking on each individual commit, which is the solution I find inconvenient :-/ Do I have to add a magic ".patch" in the URL bar somewhere ?
There's a "Files changed" tab toward the top of the page: ! Adding ".patch" to the URL is a neat hack for finding something you can download, but usually I find that pulling from the branch is nicer to work with.
Thanks for pointing that one, I always thought it only contained the original PR's changes, not the latest proposed ones :-) I'm seeing this part which remains confusing: "Any change to the maximum value set by the decoder takes effect when..." which I'm reading as "the decode first sets a size, then any change to this size ...", thus reinforces what most servers currently do. I think Kazuho's proposal to move the sentence about initial values solves this: "The dynamic table has a maximum size that is set by a decoder using the SETTINGSHEADERTABLESIZE setting; see XXX.
The encoder at both client and server is initialized with a dynamic table size of 4,096 bytes, the initial value of the SETTINGSHEADERTABLESIZE setting. Any change by the decoder to the maximum value takes effect...". This makes it clear that the initially advertised value is a change, which currently is the main point of disagreement. Proabably that we should wait for the end of new year holiday before merging it, so that other implementers for whom this is a change of behavior can have a look.
NAME NAME it would be nice if you, as implementers, could have a look at the proposals here, given that your implementations will need to be updated as well. In haproxy this results in a little ugly trick where the H2 layer has to inject an HPACK opcode (0x20). That's trivial but ugly enough that it warrants a second thought before jumping on any final solution.
NAME Apache is lazy and uses libnghttp2 for h2 protocol handling. It does not change the dynamic table size and all its handling and ACKs are done by nghttp2 transparently. If any changes are necessary, I'd expect them to come with an updated version of libnghttp2 and, since that is linked dynamically, no need to us to release anything new.
NAME I actually wonder if you failed to push the branch here, I saw new commits being pushed to URL instead.
Ugh, my bad. Having two remotes sometimes bites me. Sorry about that Willy. (And thanks for noticing Kazuho.)
No problem Martin, don't be sorry, you're the one doing the job :-) I'm almost fine, almost everything is OK but there remains one ambiguity in that sentence: "A decoder MUST treat a field block without a sufficiently small Dynamic Table Size Update instruction that follows an acknowledgment of a reduction of SETTINGSHEADERTABLESIZE as ...". It ought to be "a reduction of SETTINGSHEADERTABLESIZE below the current size of the header table size etc" (which is slightly different since we don't want to have to re-emit a DTSU if the previous value was already smaller).
Given that this principle was explained in the previous sentence, I think we can simply address this by adding the word "such" before "a reduction": "... follows an acknowledgement of such a reduction of SETTINGSHEADERTABLE_SIZE", or probably even simpler, write "acknowledgement of such a change".
Ahh, yeah, it's hard to balance correct and clear here.
I think it's OK now. NAME NAME , care to recheck ?
Good catch indeed!
OK for me as well now. Let's hope it will not cause difficulties (e.g. for those who would pre-queue stream frames).
Enqueuing stream frames (or any frame) and then allowing a settings change to occur ahead of those frames is very risky. Anything that you do in those frames might violate a changed constraint. If you must, enqueue all frames, SETTINGS included.
I generally agree, but it's a matter of design choice (or constraints). Before this change nothing implied a possible change of headers frames representation after the requests started to flow, so that was technically possible. There are not that many H2 implementations anyway so we'll see. But I also agree that here at least we keep the option of postponing the SETTINGS ACK frame, which leaves some options open if this issue is raised. Thanks!
Hi Cory, I suspect, as you suggested in your last sentence, that writing "HPACK encoder" and "HPACK decoder" here would remove any ambiguity. Of course we know it's not the HPACK encoder in terms of code that acks for example, but it's the same endpoint and that is sufficient to declare who does what.
I've taken Mike's suggestion and mixed in a few "HPACK decoder" and "HPACK encoder" statements, using "endpoint" for protocol actions (settings, connection errors). Tell if this makes more sense to you NAME or if I've messed it up.
aside the typo above, LGTM. Thanks Martin!
NAME I guess we've left it long enough for reviews, it's probably okay to merge it by now, what do you think ? As a bonus it would close the last issue.
Opening a new issue as I notice that has been merged already.
Text added by states: An encoder sends a Dynamic Table Size Update instruction after acknowledging a change of SETTINGSHEADERTABLESIZE even if it is not changing the size of the dynamic table or an increase to the maximum size is subsequently reverted before the field block is sent. I am not sure if this correct interpretation of RFC 7541, and also am concerned that this text might cause new interoperability issues. states: A change in the maximum size of the dynamic table is signaled via a dynamic table size update (see Section 6.3). This dynamic table size update MUST occur at the beginning of the first header block following the change to the dynamic table size. In HTTP/2, this follows a settings acknowledgment (see Section 6.5.3 of [HTTP2]). As can be seen, this paragraph of RFC 7541 starts "a change." When an HTTP/2 endpoint is using an HPACK encoder with a dynamic table of size 4,096 (the default) and receives SETTINGSMAXHEADERLISTSIZE of 4096, it is not changing the size of the dynamic table. My interpretation of RFC 7541 would be that it does not require Dynamic Table Update Size to be sent when the table size remains the same. Interoperability-wise, do existing servers respond with a Dynamic Table Update Size instruction when the client sends SETTINGSMAXHEADERLIST_SIZE no less than 4096? It seems to me that this newly added text suggest such behavior is required, but I'm not sure if many servers behave as such. added text indicating that endpoints MAY error-close the connection when not seeing such behavior. Even if we are to agree that Dynamic Table Size Update MUST be sent in all cases, I'm concerned that we might see more interoperability issues by suggesting that endpoints can error-close.
Yup, I think this works well. Nice work NAME
A proposal for adding GZIP compression to DATA frames. One possible resolution for .
This looks good. Thanks for putting this together. We'll see how the discussion progresses.
I realise we might also want to modify Section 8.1.3.5 Malformed Messages, to explain that Content-Length either cannot be sent if any frame is compressed, or measures the length after inflation, depending on how closely this maps to transfer encoding (URL). I suppose that's a follow-up issue for the WG to discuss.
No. You are right. Content-length applies pre-compression or post-decompression. We need to that clear. On Apr 22, 2014 4:28 PM, "Matthew Kerwin" EMAIL wrote:
Pros: selective disclosure of types possible to increase privacy and to reduce contextual info more granular types possible issuers don't have to issue multiple credentials Cons: polymorphism always is a challenge, we that with no support in SD-JWT yet to selectively disclose array elements
After further discussions it seems that multiple types might cause difficulties with JSON schemas. If multiple types are required in the future (e.g. more implementer's feedback), we can update the specification. So, let's make a single string value.
Regardless of where they're retrieved from and over time.
I put a two very small nit comments but don't care either way. They do not change the substance of the PR and +1 on the overall thing this is saying.
This came as part of interim at Denver when discussing multiple announce for same track. There needs to text that mandates, if 2 objects comes with same name, they need to be bit identical. Also needs to clarify on how long the name needs to be unique
Two changes here, one editorial and one probably-editorial: The endpoint might send a connection or a stream error of HTTP11_REQUIRED, depending on the scope of the requirement. Note that this was non-normative language, so removing the implication that it would always be a connection error simply makes clearer what was already permitted. The server might know as soon as the connection is established that it will want the cert, but want it protected by the handshake. Either endpoint, not just the client, may choose to renegotiate before sending their preface.
This patch alters the cookie parsing algorithm to treat as creating a cookie with an empty name and a value of "token". It also rejects cookies with neither names nor values (e.g. and . Tests in web-platform-tests/wpt. Closes httpwg/http-extensions.
NAME Ping?
Landing this based on the discussion in . NAME If the wording needs more cleanup, I'd appreciate feedback!
The cookie-pair ABNF rule still requires presence of . Is it intentional?
As a part of discussion in whatwg/html I've made a of the modern browsers compatibility with the RFC 6265. It appears that all browsers nowadays allows cookies without key or (in case of Safari) without value, thus making it de facto standard. However, it's debatable how cookies like should be treated: as the cookie without value or without key. Thinking of cookie jar as some kind of key/value store makes it more logical to treat such cookie as cookies without value, but on the other hand, currently most implementers treats them as the cookies with the special empty key.
Discussed at Berlin IETF; Julian points out that we should check previous discussion in cookie WG. Martin points out that we should talk to the implementation that has divergent behaviour.
Context: around URL, ticket in URL
For clarity, are we saying Chrome, Firefox, and Edge treat such a cookie as key: "" and value "foo", and Safari treats it like key: "foo" and value: ""?
Per the table linked in OP Safari serializes input as whereas others serialize as . Firefox attempted to be more strict on cookie setting lacking and found it broke a router: URL
URL is the relevant test, in particular the following subtests: sends . Chromium stores a cookie with an empty name and value of , serialized as . Firefox does the same. Safari drops the cookie entirely. Given Firefox's experience with and related bugs above, this seems like it might be baked into some user-visible sites that are unlikely to update. I'd suggest that we change this test expectation to , and update the spec accordingly. sends , , and . Chromium stores three cookies: , , and , serialized as . Firefox and Safari store two cookies: and , serialized as . The latter is clearly correct and matches the spec; filed URL to change Chromium's behavior. sends , , and .
Chromium stores three cookies: , , and , serialized as . Firefox does the same. Safari stores two cookies: and , serialized as . If we change 0004 above, then we'd update this test as well to match Chromium and Firefox. sends , , and . Chromium stores three cookies: , , and , serialized as . Firefox does the same. Safari also stores the same three cookies, but serializes them as . I think this ordering problem is similarly represented in and , and is something that can be dealt with separately from this issue. sends and . Chromium stores , and then overwrites it with . Firefox stores and ignores the empty cookie. Safari ignores both (as per 0004 and 0021 above). I think Firefox's behavior is most correct here as a logical consequence of the spec change to fix 0004, and I believe Chromium will match it once the bug filed for 0020 above is addressed. sends and . Chromium stores , and then overwrites it with . Firefox does the same. Safari ignores both. If we change 0004 as above, then Firefox and Chromium's behavior will match the spec, and the test should be updated. I'll put up a PR against the spec if folks are on board with the suggestions above.
Putting together a , I ran into more excitement: 0024 (, ), 0025 (, ), and 0026 (, ) show that Firefox overwrites with , and serializes it as "". 0028 would show the same, but it's incorrect in the WPT repository; it should contain a tab character, and the expectations are simply wrong (also in the original repo). I'd suggest that this behavior doesn't make much sense, and that it would be better for browsers to align on requiring cookies to have either a name or a value, and to ignore headers that parse with empty names and empty values. That would change the expectations for these four tests to expect a serialization of "Cookie: foo". WDYT, NAME NAME
For clarity: https://chromium-URL shows the test expectations I'd suggest we end up with.
Tl;dr: I think changing the spec to match current implementations for to produce (i.e. 0004 case) makes sense.
I think disallowing (0020 case) and (0023 case) would make sense too, but that might break things. In the 0004 case: We've been parsing as an empty name with a non-empty value for a long time, afaict. Since Firefox seems to do the same thing, I think we should definitely update the spec to match the implementations (i.e. for a Set-Cookie line without a but with a valid token, treat the token as the value and, for cookies without a name, don't put a when serializing). In the 0020 () and 0023 (empty ) cases: Judging by Chrome metrics for Cookie.HeaderLength, there is definitely non-zero usage of empty cookies, so I'm concerned that rejecting empty cookies would break things... (In the 0020 case, one could also argue that explicitly sending a Set-Cookie header of indicates intent to create a cookie, even if it is empty.) I agree it's a bit silly to allow cookies with both empty name and empty value, though. I think that's a reasonable change to make to the spec, and maybe we don't care about potentially breaking things.
Thanks, NAME I agree with you for the 0004 case. NAME would Apple be willing to change CFNetwork's behavior to match the suggestions above? For 0020 and 0023: Looking at the stable channel on for the 28 days ending on Dec 31st, 0.0025% of headers were empty, spread over 0.12% of users. This is a pretty small number in total, and a pretty small number per user; certainly within the range of changes we've been successful with in the past. I wouldn't be surprised if it broke something (because everything we do with cookies breaks something!), but I would be surprised if it broke anything critical enough to retain the behavior. It would signify an intent to create a cookie without a name and without a value. What would that intent mean? I'd like it to mean "Don't create a cookie." :)
I'm okay with your proposed changes. cc NAME NAME NAME
URL should cover the proposed changes above. (I kinda want to rewrite the whole parsing algorithm in terms of Infra to be a bit more precise, but that's a task for another patch.
:) )
I’ve pinged the relevant folks to take a look at this thread. Like me, many won’t be back until Monday.
Not sure if it's the same thing, but I've seen facebook send an empty header frequently. For example visiting URL loads a 1 pixel gif with the following URL: URL (replacing XXXX with your unique tracking reference) with the following response headers (note the blank header, third from the bottom): This then gets set in the Chrome Cookie jar with the following: ! I can't seem to find this showing in Firefox's cookie jar (even when turning off the default Enhance Tracking Protection) nor in Safari. Anyway, I'm sure a good few of us wouldn't care if this "cookie" died a death, or if Chrome changed to ignore this "cookie", and not even sure if it DOES anything (it doesn't seem to be sent in follow up HTTP requests, but that's not to say it's not looked at by some local JavaScript). However, given the prevalence of Facebook tracking I'm really surprised these sorts of cookies are only seen by 0.12% of users so thought I'd comment to note this in case those estimates are not accurate? Perhaps the stats are not picking up these cases? I've seen this on many sites and only picked the Guardian as a well-known example and guessed first time it would be on there (news sites are good ones to pick when looking for tracking pixel examples!). URL sets the same if you prefer something US based and URL sets the same (but not on the main domain) for those of you in that side of the world.
The number of 0-byte Cookie headers is only a lower bound on how many no-name-no-value cookies are in use. If such a cookie were sent along with some other cookies, it would not be logged as a 0-byte header. I don't think we have any metrics on per-cookie length, just the total length of the Cookie header. So it might be worth collecting more data? Also, that metric doesn't include cookies accessed via .
Regarding NAME comments on Facebook; I pinged someone there who will forward this to the appropriate team. It sounds like a bug to me, and not something that I think should stop us from making a decision here on the underlying question of whether an empty cookie is a thing we should support.
NAME I read your comments above as generally approving of the change suggested in URL, but cautious about how to ship it in Chrome? That feels like an important part of an eventual "Intent to Ship", rather than a discussion of what we'd like the spec to say. If we decide to accept the suggestions above, then I'm pretty confident that we can work out how and when to ship it (especially given that there's no real agreement among browsers today, so the status quo is already trifurcated as per URL above). Indeed! You're exactly right, and I should have been more clear. The 0.0025% is the number of requests (not page views, FWIW) for which we'd shift from sending an empty header to sending no header at all. That seems to me to be a change more likely to invalidate an application's expectations than shifting from to . I think this is the easier case, actually, as the serialization of an empty cookie is indistinguishable from a empty cookie jar.
Thanks for sending on NAME . I more meant it as a concern that the 0.12% of users figure sounds way too low to me given Facebooks prevalence. Note you don’t need to be a Facebook user or visit a Facebook site to get this cookie - just a site that uses Facebook advertising pixels (of which there are many!). So I still have that concern that this figure sounds way too low to me. Which then begs the question as to whether there are more cases than we think there are? Now I agree that particular example sounds like a bug and I doubt this empty cookie is being used and so don’t think blocking it off will cause a breakage, but still, I’m uneasy that the stats seem wrong and that we are using this (potentially incorrect) stat to justify the low chance of breakage with this change. There might be other cookies on other sites that will cause breakage. To be clear, I don’t actually think it will cause a lot of breakage, but would rather than was based on a stat we are comfortable to stand behind than one that we have potential concerns with. Is there any way to double check that 0.12% stat given this example?