jiebi/CodeConvo huggingface dataset:
Addresses issue
NAME You wrote "Some comments on Bufferbloat" and I am pretty sure these are interesting comments, but I cannot see any. I am afraid something went wrong and they were not published.
A good improvement. I wonder if framing it like "use the full bandwidth and nothing more" would be a more holistic approach that covers a few different requirements at once, but I have no actual text to propose.
This looks like reasonable first text pin this topic, thanks Christian (my previous comments appear already to be resolved - so happy to approve this)
by taking MT's suggestion. This is the right thing to do editorially even if it might make NAME a little sad
It is not necessary to make this claim, or any claim, about the range of values. Such a claim would need to be supported with evidence. I don't think we have such evidence. Internal documentation I have lists about 30 different types of requests that a web browser might make that were put into about 11 different categories; you could make arguments that 30 or 11 is sufficient on that basis. And you might still be wrong. The good thing here is that you don't need to justify the choice of 8 different urgencies. Strike this sentence.
thanks both, good suggestions
... and HTTP/2's positives too! protocol. However, the way HTTP/1.1 uses the underlying transport ([RFC7230], Section 6) has several characteristics that have a negative overall effect on application performance today. a time on a given TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency. I think time has shown these claims to not be great. How about cutting cruft and saying and then a tweak to a later paragraph in the intro to state that no one is perfect
It looks like you have a pull request that is dressed up as an issue :)
If you're receptive to change, I am willing to try and edit horrible XML
One change and I'm happy
: Please confirm that "i.e.," is correct here (in which case "SETTINGS changes, small frames, field section compression" should be "SETTINGS changes, small frames, and field section compression") instead of "e.g.,". Original: Most of the features that might be exploited for denial of service - i.e., SETTINGS changes, small frames, field section compression - have legitimate uses.
I think that this should probably e.g., not i.e.
implies a requirement: I would have said instead that HTTP itself doesn't care whether content adheres to this stricture, though some implementations could (or MAY) normalize line endings before sending or after receiving content that uses a media type.
Maybe we can improve the spec by just killing the whole subsection? It refers to the canonical form in MIME, then say we don't neef that, and then makes recommendations for text/* that AFAIU everbody ignores.
This was a huge deal back in 1995-96 and was necessary to bless deployed practice of sending native line endings and expecting the user agents to process them. I guess we can ignore that now? Don't be surprised if JK brings this up in IESG last call.Not seeing anything here worth saving.
This seems out of place, although I understand that versioning is very message-based. I'd suggest putting it in 15. Extending HTTP?
It's not about extending HTTP. The version number literally exists as a field of the message, or at least inherited by the context of the connection, and must be retained by recipients because of version-specific requirements. That's why we need to define both cases as part of the message abstraction.
Fair enough. Can we open the section with a sentence or two that says that it's a field of the message, to give that context? The current text is pretty abstract.
This changes Expect-CT to be a comma-separated list of directives (which may be name=value pairs), and adds some examples. Also allows the server to send multiple header fields so that they can be combined, as per URL Fixes issue ,
Would it be possible to include an example in the spec? Something like... Expect-CT: enforce; max-age=3600; report-uri="URL" As I believe most developers like to work with examples, rather than just using the spec definition as found under the heading "Response Header Field Syntax". :-)
That's what this does; the text above already has that effect. It does raise the question of whether we should add CTL to , however. Thoughts?
I believe the proposed text now is somewhat misleading, as it does not mention that CTLs are (and always have been invalid. No, that would be a breaking change.
We still need to rewrite or remove
draft-ietf-httpbis-semantics-latest currently says: However, when I implemented an HTTP/1.1 parsing library that followed this rule, it turned out to broken in the real world. Specifically, users reported that sites using Google Analytics were setting cookies with values containing the ASCII character , which is a control character (URL). And in my investigations at the time, browsers and popular clients like curl all supported this just fine. It would be great if the next round of RFCs could look into this in more detail and define the production in a way that would be acceptable to e.g. the browsers. In my library we currently reject NUL and exotic whitespace (, , , ), on the grounds that those are high-risk for interop bugs and splitting exploits, but allow all other bytes to pass through, including control characters. I don't know if that's the best solution, but in our experience it's at least closer to being real-world compatible than what the RFC draft currently says.
See . URL is what browsers implement, which is slightly more lenient than what you have there. web-platform-tests has tests for that as well.
Was this bug reported to Google Analytics?
To be clear, at Mozilla we found the same thing on routers and such. It's not an isolated incident.
As with the discussion we’re having on-thread about , is it worth us revisiting the language in this specification when we know that non-conformance is widespread?
No, control characters as a set being disallowed in header fields is a relatively new requirement, whereas HTTP has explicitly forbidden CR-only line breaks since 1993 because that is a well-known security hole. Allowing some of the control characters to pass through is not going to decrease the security of valid implementations, whereas allowing CR will only increase the number of insecure browsers subjecting their own users to cache poisoning attacks.
Hmmm - unless I'm missing something they weren't allowed in RFC 2616 either. What's new are the instructions for recipients how to deal with malformed values.
Right, that makes sense, though more strict handling of field values in 7230 was part of the move away from lenient handling for robustness in 2616.
As an HTTP implementer, I'd like to respectfully plead for you to reconsider here, and align the RFC text with the WHAT-WG text for better real-world interoperability. YOLOing together a HTTP/1.1 implementation that's interoperable but insecure is easy. Writing a secure but non-interoperable implementation is pointless, because no-one will use it. Writing a secure AND interoperable implementation is extremely difficult, because it requires that you find the narrowest possible rules that allow only the things that are required to interoperate, and reject everything else, and that's essentially impossible without browser-maker-level visibility into exactly what weird HTTP implementations are out there. The RFCs are an incredible resource for anyone who's trying to build a high-quality implementation, because they contain so much distilled wisdom on where this line is... except for bits like the field-value production, where if you follow the spec you'll get burned and end up having to YOLO something anyway. It's very frustrating to carefully follow the specs, and then be punished for it. And it makes it hard to justify following the spec versus using some YOLO implementation.
We can't align the text. HTTP has always forbidden bare CR as a line break. Almost all deployed implementations rely on that while parsing CR into field values and (CR)LF as line breaks. If we changed that now, all deployed implementations with a cache would have a security hole, instead of just the two evergreen browsers that broke their own parsers and can easily change them back. What servers have been doing (and slowly deploying) is active removal of bare CR in fields when they do character-by-character parsing, just to fix the new browser brokenness. This is a workaround.
With regard to other CTL characters, many are found in the wild, but it would be a stretch to say that they are interoperable when sent in HTTP. Some might be. I don't think we have time to validate such a change.
The WHAT-WG spec text that NAME linked above forbids NUL, CR, and LF inside field values, while allowing everything else. So I'm not suggesting allowing CR.
Re: the other control characters: if you can't validate interoperability, then that's a tough position to be in for sure. But surely there's something that would be better than the current text? Currently, all general-usage http clients MUST actively violate the spec. Even if all you can say is "you should definitely disallow NUL/CR/LF and for everything else we're not sure, use your best judgement", then that seems like it would at least be more accurate and helpful than what we have now.
It really would be interesting to see what the effect of converting-to-SP instead of preserving the CTL characters would be. That is, are those characters sent intentionally (I see that this probably is ghe case for G Analytics). Unfortunately, even if we ran an experiment right now, it wouldn't help in this LC.
FWIW URL suggests that the HTTP/2 has a "MUST reject" rule. When we achieve consensus here, the H2bis probably should align.
Yeah, specifically the CTL characters from G Analytics occur in / headers, so it's an opaque value that the server expects to get back. I don't know for sure, but my impression is that someone chose as a "clever" separator character that they knew wouldn't occur inside the values being separated, so converting to SP would probably break it.
I see. Another related question would be: is this something that's specific to cookies?
Note also that the G analytics cookies refer to an old version of custom variables in a library that has been supplanted at least twice (URL --> URL --> URL). It's possible that they were removed because of lacking interop. URL
Discussed in Feb 21 Interim; align with Fetch for hard refusal of characters, strongly caution against CTL (minus NUL) for senders / field definitions. Don't require CTL (minus NUL) to be replaced with space. CR+NUL MUST be converted to space or rejected.
In CTT that can't happen unless you can predict the COSE signature, i.e., the content of the datum. Sorry, I don't understand this. You are making a similar point in which I am also failing to grok. To me, a timestamp asserts the existence of a datum at least at the point in time when the timestamp for that datum is created. I cannot fathom an attack in which pushing the existence of the datum back in time is an attack on the intended use of the datum.
In , Orie commented that: "Security considerations seem light."_ We could add prose that succinctly describes: the attacker model (i.e., a dodgy individual trying to manipulate the COSE signer's or the relying party's local clocks), and the trust model (i.e., local clocks are untrusted, and the TSA clock is trusted by both the COSE signer and its relying parties)
The only interesting attack is when the attacker moves the RP's clock in the future.
ltgm Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >
There is limited value in some of this information. I might avoid the detail and limit that text to something like "RFC 7540 priorities had several issues that this design avoids." The purpose of the section is to describe the security consequences of the mechanism that is defined in the document. There are some DoS concerns in previous sections that might be worth noting. You might also refer to RFC 8941 considerations, the size of state commitments required to buffer PRIORITY_UPDATE, and the starvation risks involved with strict application of priorities. Most of that already exists in other sections, so this section could just be a summary of the issues with pointers.
Reorder Digest section. Cumulative PR of: NAME this patch ends the reordering and achieves: Digest header defined at §3 (pag. 7) Non-normative section moved in Annex Replaces
NAME WDYT about this roadmap? I'd address each one in a separate PR. If you agree, I can cherry-pick the first ones from your PR so you won't have to do it twice :) Digest Headers to be reordered: [x] move the "deprecated algorithms" security consideration directly in {{digest-agorithms}} [x] merge the {{digest-algorithm-encoding-examples}} in its parent section {{representation-digest}} [x] move Digest Header and Want-Digest header outside Header Field Specifications [x] move {{representation-digest}} under {{digest-header}} [x] move {{digest-algorithms}} down [x] move {{resource-representation}} examples to Annex B [x] ensure people start reading from {{representation-digest}} [x] refactor Digest to be more direct Optional: [ ] integrate examples from into {{resource representation}}
That sounds like a good plan, thanks. Please action it and I'll review promptly. This is a set of editorial changes that I think would add value to the specification readability. My jumbo PR () had some problems, so lets focus on landing the easy-to-agree items and not try to rush everything through before the submission deadline if we are uncomfortable. We can continue working on the thornier editorials even after the submission deadline.
Here's a first bunch of PRs. PTAL :) thanks for all the support!
NAME I'm trying to refactor and I have this proposal: URL we need rewording but just look at the sections ordering and let me know. The next PR to merge is
This section outline looks good. I approved, so let's merge it. What's next?
Now we have and which should end the refactoring. I think that's a reasonable cutout for IETF107 but we are clearly not over :)
All the PRs look good, even the optional one. Thanks for your work on this. Let's get them merged, then take a once-over review to catch any basic errors that might have crept in. Then one of us can cut the release.
NAME - can you review?
The client hint spec does not seem to specify if there's a maximum lifetime for the origin opt-in preferences. There seem to be spec that the data should be cleared when site data, cookies, cache, etc. are cleared, but barring that should there be some sort of reasonable limit?
I'm new to this process; I'm not sure how to add the "client-hints" label
NAME thoughts? You were the one pushing for an implicit lifetime. Do we want to cap it?
I think that what you should say is that the browser can discard this state, but it should do so only when it drops all other state for the origin (e.g., when clearing cookies). Modeling this as part of origin-bound state like that is far easier to reason about and more reliable for sites.
We already have "Implementers SHOULD support Client Hints opt-in mechanisms and MUST clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, or similar, are cleared." Do we need to also add something around origin-bound state to that?
As Safari is already capping script-set storage lifetime to 7 days (Brave does w/ cookies, plans to do for all storage too), and some other vendors have hinted at the same, I suggest a max lifetime of 7 days. Especially given the possibility that these values can be tracking vectors (discussed in the fingerprinting conversation).
The text above means that browsers that choose to set max lifetime to storage/cookies will MUST do the same for Client Hints. I don't think we need to bake in the specific max age that some UAs chose into an IETF draft.
I hear what you're saying, but the purpose of a standard is not to say "some people will act X and some folks will act Y", its to bring X and Y as close as possible. What is the use case for a lifetime of > 7 days? Like any cache value, its perf utility decreases as life time increases, but the privacy risk stays constant. Put differently, what is the concern w/ a maximum value, to at least partially constrain the privacy risk?
Sounds like the restriction you're talking about is of larger scope than Client Hints, and applies the origin storage in general. I suggest you'd try to enforce those specific values e.g.
The section "Moving Beyond RTP over QUIC" should cover the position of assessing the feasibility of the RTP family of protocols, and the size of work of any possible changes that may be required for them to be incorporated.
This We're going to need more work on RTP versus other transport protocols, but we definitely need to make this change!
I've already ranted enough about this section but I figured I'd file a ticket so it doesn't get forgotten. :)
I think what needs changing is that this is removed as a non-requirement, however I still think that we have to make it clear that a consideration "to RTP or not to RTP" must be described in the document.
I think we've now covered this, please chime up if there was anything missed.
NAME did you just forget to create the pull request?
Didn't realize you couldn't merge from the referenced issue. What do you need from me to merge the commit?
Just some indication that you think that this is ready, that's all.
Do you think we need to add a requirement for must emit? or is the not coalesce sufficient?
Now that you mention it, MUST preserve is really what we are going for.
added "MUST preserve"
There is some usefulness from both an extensibility perspective and a load balancing perspective to indicate multiple messages over an individual stream. This issue is to un-reserve the 0x02 END_MESSAGE flag to ensure that intermediaries that are deployed proxy the flag so that they are agnostic to the layered protocol and can still successfully load balance messages appropriately.
Note that this places a requirement on proxies that they cannot coalesce data frames across "END_MESSAGE" boundaries.
Discussed in Zurich with no real conclusion. Support and opposition were weak.
Discussed in Zurich; accepted in principle. Jeff to do a pull request.
Renamed ENDMESSAGE to ENDSEGMENT to avoid any confusion with HTTP messages. Feel free to re-name. Couldn't find any text that stated intermediaries could combine frames but may want to add a requirement that intermediaries must re-emit the flag at the same byte position.
NAME please check the new test vectors to make sure they pass in your system as well!
It looks good to me (If the tests are correct) URL
+1
The first example signature from fails signature verification. By changing the validity date from 1618884475 to 1618884473 the validation succeeds. I guessed that date as it is the one used in all the other signatures. So I guess that is a typo. (It would have been good to have a different created date, just to make testing less mechanical, but then the signature needs to be changed). There is then perhaps a logical mistake in the next example. The story goes that the proxy receiving the above request alters the message and signs it before sending it on. The original signature is kept and added as part of the signature. The proxy alters the header and adds a header along with a new Signature. But by changing the the proxy makes it impossible for the recipient to verify the initial signature, since that includes a component which was changed. So the spec has to either remove the component from the client request, or change the text at the end of the section which says Note: the proxy's signature does verify for me with the timestamp of the client as it appears in the spec.
Verification of claim above: The test on line 173 of had to be disabled for my tests to pass on the JVM (JS tests coming soon). All the other tests on requests from the spec (well on one I had to change the time for it to pass. Further commits should get the JS to work.
The proxy should not alter the original signature, and that signature does need to include the component. The whole point of the story is that the proxy verifies the first signature, and the service behind the proxy verifies the proxy's signature. If we can make that story more clear, I'd be glad to!
It is indeed an option to have the final recipient rely on the signature of the proxy as a verification of the originally signed message. But the text currently says "The proxy's signature and the client's original signature can be verified independently for the same message, based on the needs of the application." The "independently" reads to me as if the application (that is the server receiving the signature) should be able to verify both signatures. It seems to me that it can only verify the proxy's signature though.
But perhaps I was just misreading... It seems there is a dependence of the final recipient on the signature of the proxy. I think there is still the problem of the time being wrong...
Yes, the signature needs to be recalculated and replaced due to the typo in the timestamp (I will need to check the generation script). I can see now how that line can be misread. Though it is definitely possible for the origin server to validate the client's signature if it has additional information, like that discussed in URL and URL -- but this could be made more clear.
Note from call. Fixe subscribeDone at same time. Define a new bool type. p[ick new leatter other than b
Also make sure to fix SUBSCRIBE_DONE at the same time.
NAME - I updated, have another read and see if it looks OK. Thanks
and introduced a field to SUBSCRIBEOK, SUBSCRIBEFIN, and SUBSCRIBE_RESET. If I read the notation correctly, it has a size of 1 bit, which makes it hard to parse the rest of the message. Could we encode that information in the message type by using two types per message instead of a 1-bit field?
I think the intent is that it is one byte not one bit.
Maybe it should have been:
or just a byte field with only 2 possible values allowed (1) and (0) ..
I agree we need to keep this byte aligned however we do it.
IMO just make it a VarInt (or byte), with only values of 0 and 1 currently valid. This encoding is temporary until we nail down all of the fields/flags so we shouldn't be making life difficult or efficient.
Individual Comment: Even if it's temporary, my preference is for a one-bit field and unused/reserved bits to align, because there are no error conditions.
Have a look at PR