jiebi/CodeConvo huggingface dataset:
in the manner discussed in London: Admitting it exists, but we don't care.
Section 2 of includes these nuggets: to this specification MAY define flags. See . and but future updates to this specification (through IETF consensus) might use them to change its semantics. The first four flags (0x1, 0x2, 0x4, and 0x8) are reserved for backwards-incompatible changes; therefore, when any of them are set, the ORIGIN frame containing them MUST be ignored by clients conforming to this specification, unless the flag's semantics are understood. The remaining flags are reserved for backwards-compatible changes and do not affect processing by clients conformant to this specification. HTTP/3 frames don't have a Flags field in the generic frame layout. So, while I'm not sure we'll ever see a use of these flags in H2 ORIGIN, it might bite us later if it happened. I see a few options for dealing with this: Option 1) Defer. Future us will have a job to do trying to make H2 and H3 compatible if a flags related change is proposed. Perhaps its worth a little note to make sure people are aware of this divergence consideration. Option 2) Add a Flags field () to the HTTP/3 frame and add in all the same considerations about backards-(in)compatibility Option 3) Encode the flags in the frame type by picking a large enough value. A bit yuck. I'm leaning towards option 1.
one question is if they come on different streams can they get out order
My inclination is to send a SubscriptionEnd {} message with appropriate Reason Code set. This will help to support the case that we discussed on publisher wanting to indicate wanting to stop publishing
SUBSCRIPTIONEND and SUBSCRIPTIONEND_ERROR could be split for the graceful vs non-graceful cases.
Discussion in room seems to be rather not have an error after OK but instead use new messages or in subscribe_end message
I'd like to consolidate messages at some point, but we can revisit later.
painful words in an attempt to explain renegotiation's applicability with client-cert header to
NAME wrote: possible with HTTP1.1 and maybe needs to be discussed explicitly here or somewhere in this document? Naively I'd say that the header will be sent with the data of the most recent client cert anytime after renegotiation or post-handshake auth. And only for requests that are fully covered by the cert but that in practice making the determination of where exactly in the application data the cert messages arrived is hard to impossible so it'll be a best effort kind of thing.
maybe adjust the language around DEFLATE and ZLIB per Originally posted by NAME in URL
Copied over, to have everything in the issue here: This is the current text: This is the proposal: >The complete byte array is compressed using DEFLATE {{RFC1951}} inside the ZLIB {{RFC1950}} data format. Implementations are RECOMMENDED to use the highest compression level available. I agree that the current text is a bit weird and I wasn't really sure how to formulate it better when writing it.
More context copied over via Screenshot: !
This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.
They won't be wasted until we have 64 message types valid on unidirectional streams. We currently only have 3 valid messages types. I think you mean that we could save the message type byte if OBJECT is the only message allowed on unidirectional streams, but that's not forward-compatible.
Draft-02 strongly implies the forwarding preference is a per-object decision. thus the following sequences would be legal: [sequences are written as (group, object)] Stream 2: (0, 1), (0, 2) (0, 3) (0, 5) -- type is StreamHeaderGroup Stream 6: (0, 4) -- type is ObjectStream or Stream 2: (0, 0), (1, 0), (2, 0), (3, 0) -- type is StreamHeaderTrack Stream 6: (1,1) -- type is Object Stream etc. If someone can imagine a use case for this, that's great. If not, it would be easier to implement with different assumptions, e.g. (1) Forwarding preference is a track-level property. Thus the preference could be provided in the SUBSCRIBE_OK and we wouldn't evens strictly need four different object codepoints (though you would want the distinct formats, and might want to retain the codepoints for that reason) (2) Forwarding preference is group-level -- some groups could be aggregated under StreamHeaderTrack, but others could be under StreamHeaderGroup. If there is a StreamHeaderGroup for a group, there MUST NOT be object-level streams for that group. Again, I have little sense of the use cases out there, but I think we should explicitly decide what we are doing and make it clear in the doc.
A related question is whether forwarding preference applies across subscribes. That is, for per-group streams, a current subscriber gets all of group 12 and then the stream closes. a later subscribe in the same session asks for group 12. Obviously, this will need a new stream. So maybe the answer is no, it does not apply across subscribes
I agree, this is very difficult for a decoder to support. The target use-case is non-reference frames. In your first example, object 4 is optional so it gets its own stream.
However the receiver doesn't know that, instead it just sees a gap between 3 and 5. Does the receiver try to decode and catch any errors? How long does it wait before trying? If I want minimal latency, do I have to partially decode (on a per codec basis) to get the frame dependency graph? I really don't like this option. I instead want an explicit way to know that this object is a non-reference frame. Ideas: Make a separate track for non-reference frames and SVC layers. Receive a formula that every 3x+1 object is optional? Receive a live object catalog containing metadata about each object. My vote is a separate track and each track has a uniform forwarding preference.
I like the idea of uniform forwrarding preference for a track. That's what I had in mind when we landed that PR. I can't think of any use cases this restriction prevents.
I think the consensus in Denver was to have one preference per track
just to be clear , the preference is set as track level property and can have 4 values - track, object, group and datagram.
Yes, although for various reasons the PR I'm doing is going to make it subscription-level property. I think is hard to write it otherwise, and I can just about see a use case for it.
When a few of us discussed it last week, the feeling was that if it came back in the SUBSCRIBEOK, and Objects started arriving before the SUBSCRIBEOK, the receiver wouldn't know how to process the incoming Objects. In the past, we've decided we don't like that, so the feeling was to land a PR to add the restriction now, and then we can talk more about wire format changes. NAME Is Object decoding not an issue for some reason I'm forgetting? Or were you thinking that buffering Objects was fine?
I am arguing that buffering objects is fine. The usual case, I think, is that SUBSCRIBE_OK arrives first. It's irritating we're using a byte in the object encoding (and creating new error conditions to check for) just to avoid buffering. But I can live with keeping it for now.
This is an improvement, though I would still like to get rid of all the wasted bits
NAME please take a look!
Without going through a proxy, clients implement CNAME cloaking mitigations on the basis of DNS information they see during resolution, which is totally reasonable. If resolution is subverted (or whatever) and the CNAME information is modified, these client checks might not work. When going through a proxy, the proxy is the one doing DNS resolution, so it seems like any sort of funny business that one might do to DNS answers for the proxy might affect the client's ability to implement cloaking mitigations correctly. The security considerations might benefit from a bit of expansion to cover this additional aspect of the threat model.
Followup for .
The code for the IANA policies in Section 11.1 looks like this: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.
Since next-hop-aliases is a String parameter, the syntax allows an empty string . In cases where there is no chain, is it advisable to send the empty string to indicate this, rather than omitting the parameter? If so, it might help to add a sentence somewhere that highlights this usage type.
That's a good question! I don't think there needs to be a normative requirement here, but I think it's reasonable to have signify that there were no aliases.
This mention is clear. LGTM
align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.
and . There was consensus in Cambridge that removing the special meaning of zero length gets rid of difficult code, removes potental foot guns, saves a byte, and enables actual zero length payloads, which supposedly has use cases.
Since message (6. Messages) will be the main piece of info of MOQ I think we should try to minimize its size. Assuming most of the messages send to the wire will be objects inside a quic stream, the length should be NOT needed. Could we use 1 bit in "type" to indicate if length is present, we could save some bytes without overcomplicating the protocol
The length of a QUIC stream is only known after the FIN bit is received(ie the end of QUIC stream). Putting the length in the message header can ensure the size of stream is known at the beginning of the stream.
The size of an OBJECT is a varint so that's a single byte when 0. Even in the situation where you're sending an OBJECT per frame, that's what like 100 OBJECTs per second?. That's 100B/s while the media might average 375,000B/s (3Mb/s). But yeah, we can optimize when the draft is closer to completion and things are more concrete. I like how QUIC STREAM frames are encoded, where the frame type indicates if fields are present (ex. length).
This issue is related to the question of what types of lengths we'll support, and whether we'll support those that go to the end of a quic stream (aka infinite length). "unknown" payloads where they're a delimiter of some sort had no support, because you have to do extra parsing. This issue is about two types: Object and Object + Length, which has support from the WG. Martin to roll into PR
From Cambridge: Martin will put this in a separate PR once lands
In semantics 7.7: I found where (in the discussion of normalization in §4.2.3) we say to replace the empty path with "/" for non-OPTIONS requests. I couldn't find anywhere "above" where it was noted to replace an empty path with "*" (presumably, for the OPTIONS requests), though.
This is a reference to text that was moved to HTTP/1.1 because it is version specific. I suggest we replace it with
LGTM
Here is some draft text. In principle we don't need any of this at all: as this text shows, all of the relevant guidance is already present in both semantics and H2. I've elected to throw up some possible text, but if we wanted to say that some or all of it is entirely redundant with existing specifications then I'm happy to do so.
Upgrade, Transfer-Encoding, Content-Length, Connection, and anything listed in Connection MUST NOT be forwarded without modification. See also .
Note that this probably goes in
I have no personal knowledge of this issue, but it came up on the #whatwg IRC channel. URL describes Safari rejecting responses that contain the header field, while other browsers accept it. It'd be good to converge the major clients on a single behavior and, if that's not the behavior currently specified, update the spec to match.
To be clear, that's nginx being spectacularly broken by forwarding the header field. I'd characterise the philosophy of H2 as being strict with errors that endanger the whole connection -- and counts the server asking for an upgrade in a context where it doesn't make sense as qualifying as such. While I'd be surprised if folks wanted to relax the former (the strictness is a net win for H2), the latter might be worth revisiting, not because nginx is broken, but because H1's use of headers for connection-level mechanisms turned out to be so broken. I'm also not sure that aligning all clients to be so permissive is such a great idea; accommodating brokenness like this is a race to the bottom, and while it might be the only practical path when you have to interoperate with a large and extremely diverse pool of existing deployment (HTML), there aren't that many HTTP implementations that can move the needle. Interop might be better served by holding the line and forcing broken servers to address their problems.
Additionally, it seems broken for Apache to send the header when the connection between nginx and Apache is over TLS.
Filed .
Apache treats the effects of sending over TLS as a UA-side bug. :-(
Yeah, this looks bad. The spec is fairly unambiguous about the requirement to ignore Upgrade in one place. But it also prohibits the use of Connection, which implies that you can't use Upgrade. I think that we should fix this, potentially along with . I hope that we are able to convince NAME to change Apache here. There is no value in sending this value.
FYI analysis,
NAME PTAL.
Client/Server Messaging still is HTTP/1.1-specific. Suggested deletions below: Also, trailers?
Textual reason-phrase is also 1.1 specific.
NAME what's the implication of that? It's already suggested to be deleted.
It wasn't in a previous iteration of your suggestion -- see your edit history. Perhaps we noticed this in parallel?
Ah ;)
Somewhat related is .
This text seems out of place in 3.2 Storing Responses to Authenticated Requests. It also omits .
It seems like it's covered by 4.2.4 pretty completely.
Apologies for the lateness, but going through , I think we need to adjust handling of invalid headers: Right now, it's that caches SHOULD treat responses with invalid values as stale. However: No cache tested treats a response with in this manner; all ignore the field. Only Fastly and Firefox treat a response with in this manner; the rest ignore the field. Interestingly, most caches do consider a response with to be stale, except for Apache and Chrome. We specify that the first field line should be used when multiple are present. That's almost universally adhered to (with one deviation by Safari), but we omit multiple values on the same field line from this rule (which are treated as invalids as per above). However: When that line is , all caches reuse the response. When that line is , only Safari and Apache reuse it. This suggests that we could align with current implementations and improve interoperability by: Specifying that invalid fields should be ignored, not make the response stale. This is nearly universal practice. Specifying that the first field value should be used when multiple can be parsed. This is also nearly universal practice.
some content-coding are "not deterministic" ;) not only encryption-related ones.
NAME great! I applied them :) Feel free to merge!
merged, thanks
James Manger wrote:
yeah I think RFC 8188 was the target of the section here. NAME can you recall? What can we add to make this section a bit more clear?
That's correct. And the suggestion wrt different compression levels is correct to! This is worth mentioning and maybe highlight that it applies to a specific kind of content codings.
says: What about multiple ?
I think the right approach here is to require adherence to the most restrictive directive received, but I want to write some more tests first.
OK, the . In a nutshell: No implementation follows the more conservative when multiple are received, either on the same line or separate lines If the directives occur on the same line, most implementations (except Firefox and Apache) prefer the first occurrence. If the directives occur on separate lines, the behaviour is about the same, except that nginx flips and prefers the second line. OTOH most implementations do honour a stricter directive (e.g., or in the presence of more liberal ones like ; the only exceptions there are nuster (a new implementation) and Fastly (this is a known issue). So it seems like the most interoperable thing to do would be to document that when a directive with an argument (like ) appears, the first occurrence should take precedence; however, conflicting directives (like and ) should defer to the strictest.
by allowing the use of a single, protected header parameter instead of a protected and unprotected pair, for reasons described in the issue. This allows implementations to avoid the risk highlighted at the end of , at the expense of a slightly larger protected header. This is not a purely theoretical concern, the most widely used signing service inside Microsoft has implemented this choice, and the separate from Microsoft has too.
The current text mandates the presence of in the protected header when using x509: URL, and allows an unprotected x5chain: URL I propose that the specification allows in the protected header, ideally as a substitute for , but in addition otherwise. The motivation for this change is to add a degree of integrity protection over , and blame for malicious payload otherwise. The current set up does not authenticate or integrity protect the contents of x5chain, only the leaf, which opens up some opportunities for attacks targeting x509 parsers. I can see why this minimal binding can be desirable in some cases (caching large cert chains), but servers that wish to be stricter to reduce their attack surface should be able to.
Thanks for the fix. Seems quite valuable to the overall operation! LGTM!LGTM thanks. For completeness of the record, I was previously against mandatory x5chain and mandatory deep, possibly online checks of the links in the chain. This PR looks eminently sensible for people who want to rely on x5chainDiscussion at the editors meeting to approve. LGTM
Fixes Issue
Thanks NAME I think the two folks should be acknowledged and the small change around the claim incorporated. Then I think this should be merged and we should publish a -04 as basically a bug fix. The issue NAME URL found kinda undermines the whole point of SD-JWT and we should have a published version out that fixes that.
When decoys are used (_sd members not corresponding to a disclosure are added) the says to I imagine this is not intended and the holder should ignore missing disclosures instead? Same in
Actually the following in doesn't make sense to me at all since the whole point is to selectively not release disclosures.
Good point/catch Filip. I think the intent was to say that if a disclosure is found that isn't referenced by a _sd hash value, that should be a rejection. But the language got turned around somewhat. I think anyway. It needs to be fixed or clarified regardless though.
Processing by the Holder: This seems fine to me. In the context, "the digests" refers to "the digests of the Disclosures". If there is a Disclosure that hashes to a digest not found in any _sd array, the SD-JWT is invalid. Maybe we can clarify by modifying this to: Verification by the Verifier: This is wrong and should read "If no such Disclosure can be found, the digests MUST be ignored." Thanks for bringing this up, Filip!
Don't we then also need something at the end of Verification by the Verifier - that makes sure all of the provided disclosures match a digest in the payload and reject if that is not the case or am I missing something here?
That would force the Holder to act correctly, but would it provide any benefit beyond that?
The changes above are included in PR - please review NAME NAME
PR merged
This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:
As they relate to changes in SETTINGSHEADERTABLE_SIZE. This is the strict, by-the-book interpretation. That is, if the value changes, you have to send the update, even if it is pointless (that is, you aren't changing the size of the table). Note that I'm eliding the point about multiple instructions, which are necessary if the decoder reduces the maximum below the current size. The only nod in that direction is "at least one" and a reference to the section that talks about the need for multiple updates. This pulls in more of RFC 7541 than I might have liked, but we have to deal with the integration somewhere and this seems like a reasonable place to do that. It might have been better to put this text in a -bis revision of RFC 7541, but we decided to leave that document as-is.
LGTM, this is a nice clarification that removes the possibility of a different interpretation that's known to have caused interoperability issues (nghttp2 vs haproxy). Let's merge it!
Oh I see this PR already being merged. Opened .
I think this PR is in the correct direction. Endpoints have to process instructions using dynamic table, even when they advertise SETTINGSMAXHEADERLISTSIZE of zero. That is because the default is 4096. We did fix this problem in QPACK, but HPACK had already shipped. OTOH, I have concerns regarding new text suggesting Dynamic Table Update Size be sent even when there is no change in the size.I agree with Willy, this is a really good clarification.