jiebi/CodeConvo huggingface dataset:
After some sleep, I've read through the section and noticed a few other minor inconsistencies. This alters the structure slightly, as well as replacing the first sentence with a more accurate one. Supercedes . .
+1, thanks
LGTM
Merged by RFC editor.
We are working on a HTTP/2 library and we are a bit confused and we would like to get it right. Is it correct that after a sender sent a frame with some to a receiver, the sender may still open new streams, even with stream identifiers higher than the sent in the frame? That is the frame and the only limit the ability of the receiver? If this is correct, and I believe it is, then I find the following sentence in the first paragraph at confusing. In my opinion it should say something of the like Thanks.
I am also intersted in getting clarity on this topic. It seems what the "spirit" of the is something like: Each endpoint maintains the goaway last stream id from its peer. When a goaway is received then no local streams can be created (i.e. streams can only transition to ), and all local streams with > from the goaway frame are closed (or as the spec says ). Remote streams can still be opened, and to ensure a graceful connection shutdown a goaway frame should be sent in response.
Not quite: Upon receipt of GOAWAY, new streams can be created, but with the following restrictions: those with stream identifiers higher than the will be ignored. Those with stream identifiers lower or equal are subject to the usual risk of loss, but they might be processed. Success is determined by what happens on the stream, of course.
NAME - Can you clarify the following from : This is what lead me to believe that streams can not be "created" after receiving a ?
Hmm. I'd forgotten that. That is in conflict with the graceful shutdown we've specified. I think that we need to take this to the list. This seems like a genuine bug.
Thanks for the quick response NAME Would you prefer to bring the issue to the list?
I'm just trying to formulate something.
hmm I see NAME As a follow up, does the in the GOAWAY have to be the identifier of a stream that actually exists or could it also just be a "random number"?
The intent was to say that the receiver of a GOAWAY can't create new streams higher than the value in GOAWAY. Let me check back in tomorrow; maybe fresh eyes will add perspective.
So the intention of the change is allow receiver of GOAWAY are still allowed to create stream lower or equal to received last-stream-id, accepting the fact that those streams are ignored by peer? As the graceful shutdown process as described in draft 17, server first sending GOAWAY with (2^31) - 1 starts to ignore any new streams created by peer and after some time (this ensures that GOAWAY is reached to the client), server sends another GOAWAY with updated last-stream-id where processing has occurred already.
NAME the intent of the change is to not change anything :) The process has been unclear, but the point is that if you receive GOAWAY with a last-stream-id greater than anything you have initiated, you can use what space remains for new streams. What that means is that you can issue new requests on that connection while you take the time to create a replacement connection. This was considered critical for . That means that 2^31-1 serves only as a warning of impending closure, though in theory it need not change any behaviour for the existing connection. I'd take steps to make a replacement connection though.
Thank you for clarification!
Here is a link to NAME doc from the mailing list which provides additional clarity to this issue URL
Latest PR is much more comfortable to me. Thanks!
Basically, it saves the effort of writing stuff that you know to be empty. It's not a critical feature, but it turns out to be a simple way to deal with not sending trailers or a body. In the extreme, you can also drop headers to produce the simplest and shortest HTTP message ever: 0x0140c8. CLoses .
Hey David, I've made some larger edits here to factor the truncation text better. I've included your normative language.
The draft mentions that messages can be truncated in some places, but not in others. I think it would help to explain why one would want to truncated a message.
This is really just a neat way to avoid having to write out all of the pieces of a message. So if you don't have trailers, it's OK not to say "I have 0 trailers". The decoder is required to deal with it. Before you say "that's hard", you don't need to change the parser to deal with truncation. Adding three zero-valued bytes to the end of any message you receive does the job just fine. If it isn't truncated, those will be treated as padding.
Thanks
yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change
adds an example of a request with no payload body (eg. HEAD) mention an use-case in the Signature section.
NAME do you think this is consistent with content-coding like aes128gcm?
An example of using Digest in a request with no payload body. There is a misconceptions that Digest does not apply to request with no payload body. As it's not a special case URL for sha-256 we can just use Other algorithms are free to define a different computation, and the examples will only be tied to sha-256
Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:
We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.
This responds to an AD question in review. The text is proposed to shed some light on how to go about evaluating a new CC algorithm, and when to use different approaches. It could be enough, or it could be improved, please think about how best to say this.
Thanks for this.. this looks like very good expression of the expectations on how one can think of evaluating the candidate congestion control algorithms without going into lengthy details. For the sake of clarity, it seems like the word "overload" (in the quoted sentence below) needs some explanation on what exactly we mean here - I am assuming we are referring to typical congestion scenarios on the path due to packet inflow and out flow mismatch in a bottleneck network node. >>"For many algorithms, an initial evaluation will consider individual protocol mechanisms in a simulator to analyse their stability and safety across a wide range of conditions, including overload".
overload, aka a lot more traffic than the path can handle... rather than typical congestion. Martin may have suggested wording...
While section 5 expects to do well-round of evaluations, it does not specify where or how to do the evaluation. Does the congestion control proposals provide the evaluation results in a simulator or in a real lab setup or in a controlled part of the Internet or over the Internet? While it is understandable that an accurate description on the evaluation environment is tough to define but the specification should at least mention what is good enough environment to evaluation on, or state it does not really matter.
See below:On 27 May 2024, at 10:50, Zaheduzzaman Sarker NAME wrote: While section 5 expects to do well-round of evaluations, it does not specify where or how to do the evaluation. Does the congestion control proposals provide the evaluation results in a simulator or in a real lab setup or in a controlled part of the Internet or over the Internet? While it is understandable that an accurate description on the evaluation environment is tough to define but the specification should at least mention what is good enough environment to evaluation on, or state it does not really matter. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: NAME I am not sure how we add guidance … surely all of these method can be appropriate (more so for some of the evaluations) when bringing new work to the IETF.
When last calling a draft - it would be good to see more than one approach where possible. Simulation ought to be better in understanding stability and identifying worst case impact; real lab or controlled tested could be good for understanding typical interactions with other traffic. I still wonder what we can best advise?Gorry Postscript: Reading again: my comment is about testing specific new CC mechanisms, if we're talking about a new CC algorithm (not just a new technique), then I agree with Martin below.
This is covered in Section 3, which is becoming Section 2: Is that good enough?
I have noticed that section. I think it is great that we are somewhat defining the criteria for a PS. But still we are not giving any hint on - say, if simulaiton results are good enough to be considered as experimental or shall we at least want to see some controlled testbed evaluations, or put it like this - what is considered as bare minimum empirical evidence? I would be great if we can put some clarity here.
I think we ought to expect some experiment results ... but how detailed, rather depends on what is being proposed. Having some experiments (even at large scale) and no simulation of theory (e.g. on how a method treats overload) would also seem very dangerous to me. These have always been the case in the past - i.e. TSVWG has pushed back to ICCRG to see experimental results AND some simulation/analysis when it comes to CC.
NAME are you saying we are just fine with some expection on evidence of experiments without specifying what is the minimum required environ to test in? we do have test cases defined for new algorithm testing, can't we at least say get inspiration or use them in the experiments?
Aha - I think you're suggesting we provide examples (rather than requirements) and we could refer to RFCs? If so, I'll try a PR.
I am not 100% sure this is necessary but given the AD review I'm happy to include it now.Just one little nit, but it looks good.
NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!
This PR updates SCRAPI to match the latest version of the architecture.
I tried pushing a revision to the datatracker from my fork... but it did not work... so unless this is published by some other author with write access before monday, we will be -00 for a solid IETF with no updates : )
Merging based on requests to meet the draft cut off... assuming CI passes
:ship: itWe should get this up ASAP before the cutoff and prior to hackathon
evaluating false on a duplicate change request sending 2xx without validator for reasons unknown.
Hmm, of course, now I found another related message in my archives that prompted me to remember why the requirement was added. I should probably rewrite the paragraph (without that requirement) and describe the edge case as a note.
RFC7232 in URL has the following clause: It doesn't really explain what security or performance considerations are leading to such a requirement, but it calls for a lot of infrastructure and design work to implement it because that logic can be implemented only if the server is stateful. The stateless server cannot comply with such a requirement. See related mail list thread: URL Either RFC should explain why such logic MUST be implemented or relax "MUST" into "SHOULD" in that clause or remove that clause completely.
Should I submit an errata proposing to remove the following clause from RFC 7232, section 3.1: " In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent" It seems like nobody can recall/explain why this clause is there.
I finally found the original commit 303b82b12a53c170f6f755aaaf8840ac1240aa77
And the discussion motivating the change is under . Certainly the intent was to remove the constraint that an error be sent when a duplicate request is made, so the extra limitations were to reduce edge cases.
It is not an errata. This is the right place to discuss it and either find a better wording or strike the text.
Thanks, NAME for finding the original commit and your response! Sending response for repeating requests makes total sense. My issue is about a sub-condition of response that is stated in the RFC7232. In the original commit that you referenced that sub-condition is stated as: I think I understand the original recommendation not to send back. It would be better to replace with there though. But in RFC7232 that sub-condition clause is changed to: The reason of not sending with back is not explained in RFC7232 and nobody can remember why it is there or explain this requirement. Complying with this requires dev effort and extra infra since we would need to track immediate previous requests from each agent.
Our API servers are light-weight and stateless so this is a huge requirement for us. Instead, we would prefer a way simpler approach of always sending back along with responses, but we need to comply with RFC7232 thus this discussion. So, the proposal is to do one of the following (preferred) Remove the following clause from RFC7232: (If aforementioned clause is kept) Explain the reason of not sending in that sub-condition (at least) Change to in that clause.
These requirements were motivated by a tiny edge case related to protecting partial updates after two clients simultaneously try a PUT. However, I can't remember if it was when one succeeds and one fails, or one or both responses are lost and they try again, or something like that, nor can I remember what difference was made by not sending ETag. Hence, I intend to remove the requirement as being too obscure to implement in a testable way.
Related to and HTTP request proxies use "Proxy-Authenticate" in order to distinguish proxy authentication from destination authentication ("WWW-Authenticate") in the mixed bag of headers that is presented to the proxy. Classic HTTP CONNECT proxies don't have that problem, but they still use "Proxy-Authenticate", probably just for consistency. The MASQUE RFCs don't say anything about which authentication headers to use. "connect-tcp" and MASQUE should definitely follow the same rules, whatever they are. NAME noted that RFC 9110 says "the Proxy-Authenticate header field applies only to the next outbound client on the response chain". This implies that a general-purpose gateway is not expected to forward Proxy-Authenticate headers. However, there is actually no such thing as a general-purpose gateway for Extended CONNECT, so this seems somewhat moot. Personally, I think that our guidance should probably also line up with what we want to say for which is (in my view, despite some authors' protestations) a modernized HTTP request proxy.
An interesting related question is whether MASQUEish resources can be authenticated with other methods, like cookies and bearer tokens. If so, I think they are essentially "content-like" and should probably use WWW-Authenticate. If not, they are essentially distinct, and could conveniently be marked as such with "Proxy-Authenticate". Or perhaps they are both, depending on the context...
I somewhat think it's both — it's content and the proxy.
NAME Thank you for opening the issue. If we are to consider extended CONNECT gateways as proxies, then the question would be what the URI of the connect-tcp request means. RFC 9110 says that target URI specifies the origin. It is only because all the existing extended CONNECT family deals with origins that the TLS handshakes to those servers implementing the extended CONNECT family can be validated using certificates issued for that origin. To conclude, to me in seems that the use of WWW-Authenticate is mandated by the using URI as the target. PS. Note also that RFC 8441 specifically explains how proxies can be used between the client and the extended CONNECT target, see .
I don't think anything is really mandated. Within the current language of RFC 9110, I think we are free to choose either interpretation.
If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?
separates MESSAGING and SEMANTICS concepts (Eg. fields)
Thanks! :tada:
The spec relies only on HTTP Semantics and not on HTTP/1.1 messaging. [ ] improve wording [ ] switch to http-core Check all references to Messaging and consider replacing them using Semantic. See URL
NAME NAME NAME I was re-reading the spec after the more recent filed issues, and I think that switching this draft to HTTP Core terminology (eg. I-D.ietf-httpbis-semantics ) we could have a more consistent background for taking the right decisions about things like transformations, intermediaries.
This should be taken care of with , NAME please re-open with comment if there are more things to be done.