jiebi/CodeConvo huggingface dataset:
(modulo some number of 0's at either end) Any real value (regardless of storage implementation) in the range -(1e14-0.05) to (1e14-0.05), exclusive, should serialize to its closest valid sh-float representation. (rounding ties towards an even least-significant-digit) Is that reasonable?
Discussed in Singapore: will discuss on list, but sense in the room is to have a fixed point. Hum in the room prefers fixed point. (Need to still determine number of decimals; q-value uses 3).
Specifically pinging NAME NAME NAME for thoughts re: moving float to fixed-point (straw-man: three digits). This seemed to have strong support in the room, but wanted to make sure you're comfortable with it.
Would fixed point be materially different that what is currently specced? Currently, the spec implies a fixed-point with 6 digits of precision, and a maximum of 15 total digits, which (not at all coincidentally) is the same range that is guaranteed to round trip through an IEEE-754 binary64 representation, which is useful for actual implementations. Edit: I see the three-digit difference now; would the integer portion be restricted to 12 digits in that case?
Yes.
I don't have a strong opinion on switching to 12+3 fixed; I think it would cover all of the use cases that I can currently imagine (and I'm trying hard to discount any sunk costs from implementing the previous draft :stuckouttongue:) If implementation complexity (or perceived complexity) factors in to the decision at all, Chrome's current sh-float serializer, which passes the public test suite, is
If people think it's useful to have a fixed-point number, and can settle on the optimal number of digits for most of their use-cases, then
The (only!) two "real" reason we have float/decimal in the first place is values and subsecond resolution time-{intervals,stamps}, and the one "unreal" reason is that JSON offered that. I think has three decimals, either by norm or convention. Time-intervals such as "process-time for this request" are often sub-millisecond, and that has by and large been the argument for "at least six decimals".
Time-intervals do not convincingly overcome Gettys 1st rule[1] or Phil Karltons rule[2]. so 12.3 would be fine with me. [1] Do not add new functionality unless an implementor cannot complete a real application without it. [2] The only thing worse than generalizing from one example is generalizing from no examples at all.
These days at least, it's by specification. It's a number in the range 0.000 to 1.000, and all algorithms I know of that use it would be just as well served by an integer from 0 to 1000. So the only reason to include the dot is if we want to backport existing headers as-is. Not backporting existing headers was a justification for some decisions earlier on, so if that's been reversed, should we revisit some of those other decisions?
Although thinking more about it, most of the earlier decisions are sort of OBE, so it's maybe not such a big deal.
PTAL
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.
It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.
NAME - I am looking at , and wondering if I understand our point in our draft. Is it accurate to describe what WARP-04 is doing now, as ? If I understand the point, it's that we have to rev the specification, and implementations, in order to add a new package (because implementations that only support Container Format 0x0 for fMP4 don't know what to do with Container Format 0x1), so the distinction we are making seems (to me) to be about whether the protocol specification uses a generic method to tell a receiver how to decode media, rather than whether the protocol specification describes methods itself. Please let me know what you think, because I'm pretty sure I know what I want to say, unless I'm confused.
Starting thesis: The specification should support CMAF, in addition to CMAF, support non-contained {"RAW Elementary bitstream") media, and have agility to accommodate future container formats
A bunch of good comments get made in room but from requirement point of view, I think we need to have the ability to use something that has less overhead than CMAF particularly for audio. I don't see the need to use multiple types of containers in the same session and have them synchronized.
This issue was discussed at the MOQ interim meeting on 2023-01-31 - notes from that meeting are , and included here by reference. Anyone working on a PR for this issue should take a look at the discussion notes.
Hi, NAME would you be able to do a PR for this issue? This isn't my area of clue.
On today's authors' call, we think the starting point is now have agility to accommodate a variety of container formats support CMAF, support media formats that are not processed by relays (and relay-related MOQ capabilities) This document should also describe the requirements for additional container formats.
NAME - do you think what's in the document now (which isn't quite this ^^^^) is sufficient for an adoption call, or should we do a quick PR just retitling and rearranging the subsections?
We want agility, and we'll say that as a requirement, but we don't care what a MTI packaging would be (CMAF, fMP4, don't care), and we can defer to the protocol specification(s) (ex.
This PR removes the requirement of checking the request's redirect chain during the computation of same-site-ness. This is being done because RFC6265bis is blocked by this work but we have yet to find a way to implement it in a web compatible way. In the interest of moving RFC6265bis forward the requirement is being removed.
The work to re-add the requirement back into RFC6265tris is being track by issue
Yeah, we did implement this - but we had to back it out (and re-spin stable, IIRC?) because it broke too many sites. :(
Correct, Chrome had to disable the change. Firefox had a similar experience.
We noticed a difference between Firefox & Chrome’s behavior for same-site cookies. Specifically, if a web page is requesting a resource whose final redirect target is same-site with the web page, . Firefox follows what was originally decided in URL and specified in recent i.e., Firefox looks at the whole redirect chain. For context: Firefox shipped SameSite=Lax by default this January and had to backpedal due to this (and some other webcompat issues). Firefox does not ship SameSite=Lax as the default setting for new cookies as of now. While we’re still working on our own metrics, we’ve noticed that Chrome is seeing about 1% of page loads potentially affected, which seems prohibitively high. At the same time, we would prefer not to weaken our implementation of explicit SameSite cookies, given that the redirect check was specifically added to prevent CSRF abuse scenarios. With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie. NAME NAME it would be nice to hear some thoughts about this idea and also NAME how other browsers may have implemented . CC: NAME NAME NAME NAME NAME NAME
Yeah, I agree this is unfortunate. We did , but it broke a few sites and was backed out (or rather, put behind an off-by-default feature flag). NAME has been collecting better metrics so we can hopefully make progress on this. Can you give some more detail what you're thinking here? (also cc NAME


With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie.
Firefox is already enforcing that all redirects are same-site for cookies that have an explicit or strict attribute. We would like to keep that restriction of course. From my understanding the idea would be that only cookies that don't define their own SameSite attribute and are then "lax-by-default" we would ignore the redirects.
As a side note, Chrome does send with these redirected sub-resource requests, so internally the networking code does seem to know the correct same-site value of the request. Obviously we'd like to do the more secure behavior all the time, but we are committed to doing the specified secure behavior for explicit SameSite cookies. Firefox has enforced this for explicit SameSite cookies for maybe around a year and has not suffered a noticeable amount of web incompatibility. We are in the (slow!) process of gathering telemetry to measure the impact of this on laxByDefault vs explictly SameSite cookies. Our hope is that we can convince Chrome folks to honor the spec for explicit SameSite cookies so that users and sites will be secure as promised by the spec, and that Firefox will be less likely to run into Web Compatibility problems in the future because of this. And that if we must weaken the behavior of laxByDefault (as it appears we must based on site breakage) that we explicitly change the spec to say "lax-ish by default" cookies follow Chrome's current behavior of ignoring redirects and comparing only the originator and the final request URL.
Hello and sorry for my late response. Our (Chrome's) metrics continue to show around 1% of page loads containing 1 or more cookies that would be blocked by this enforcement. While I'm unable to share numbers (yet, I'll add them to URL once they're approved) I can say that the vast majority of values triggering this are unspecified (lax by default). I wonder then if many of these cookies are likely those being accessed after a POST request from some login or payment flow redirect chain. I don't have any data to back this hunch up but URL hints this may be the case. If it is then perhaps we can tie the redirect chain enforcement to the 2 min Lax+POST mitigation. I.e.: Allow unspecified cookies to be accessible after cross-site redirects for up to 2 minutes.
While I worry this will further ossify that "temporary" mitigation it feels better than a blanket except for unspecified cookies. Given our metrics I don't think your proposal is unreasonable, but the more we can tighten the restriction the better. Any thoughts? Does Firefox have any data that could support or refute my idea? (Tangentially: I'd still like to see the 2 min exception removed, but I get a headache even thinking about it.)
tagging NAME NAME for visibility to the above comment. I think tying this to the 2 minute exception is fairly reasonable - 1% of page loads is sadly much too high to ship what the spec describes in any reasonable time frame. Perhaps some pages would still break, but it's worth a shot. And I agree we should change the spec to match (whatever becomes) reality here.
What about the idea of differentiating between explicit and -defaulted ? Not ideal, but then at least there won't be a security regression for those who opt into . Then for -defaulted we could do something along the lines you propose, in name of webcompat.
Right, we already differentiate between explicitly Lax () and unspecified () when it comes to the 2 min Lax+POST mitigation. Only the unspecified cookies qualify for that mitigation, explicitly Lax do not. (Perhaps it would have been better to name it Unspecified+POST, oh well) I'm suggesting to continue that pattern for the redirect chain exception, so I think we're in agreement.
NAME Yes, that's aligned with our thinking right now. Do you have numbers that can help us gain more clarity for these exact cases (a redirect where the final URL is same-site, but the overall chain is to be considered cross-site, also called "boomerang redirect") and split up into explicit-lax and default-lax? We're still in the process of collecting those within Firefox, but are obviously interested in your insights so far.
NAME I think URL has what you want. Those numbers are from roughly a week ago. tl;dr Between 80-90% of cookies are unspecified/default lax. Cookies that are being newly written are on the higher end of the range, cookies being read are lower.
Hi! John from Apple WebKit here.
If we standardize different behavior for default vs explicit SameSite=lax … We increase the complexity of SameSite cookies significantly. Is that desirable? Will developers be able to know the difference without this effectively being displayed as an additional cookie attribute in developer tools? Are we arriving at the desired end state or piling on more legacy and technical debt? It looks to me like this should instead be a fourth SameSite value, beside none, lax, and strict. Then we’ll have to decide if the new, fourth value is the default or the old explicit lax. I generally don’t like fixing legacy problems by increased spec complexity since it doesn’t help the web/Internet progress. I will bring this up with the CFNetwork folks at Apple to see what they have to say.
Hi John, You bring up some good points. I'm curious if the CFNetwork folks had anything to add.
I think what's under discussion is making the fourth value explicit in the specification. It apparently is already a thing in some implementations. I'm not sure we have a good reason to expose it in syntax though. But yeah, a clear name in the specification would help with tooling and such.
+1
"Default" is an explicit value for the in the algorithms and storage model defined in Section 5. It's not a part of the syntax. Unfortunately it looks like the algorithm only sets the if there's an explicit SameSite attribute in step 17 ("Default" is used for an otherwise unknown value). Presumably the should be initialized to "Default" somewhere, but that's an assumption and not explicit. The value of same-site-flag is technically undefined if there isn't a SameSite attribute and that's clearly not the intent.
Hi, Zhenchao Li from Apple working on CFNetwork. This change sounds quite complex to me. Although, if it means minimizing website breakage and tightening cookie restriction, I'm in favor of explicitly adding the behavior to the RFC. It does sound like we need to move from "SameSite=lax by default" to "SameSite=[fourth value] by default". Also, "default" still needs to be a separate state persisted in "Storage Model" so as not to be conflated any time.
(I believe this is intended by latest draft, but as NAME pointed this might need some changes to the Storage Model section) NAME Could you help clarify more about "2 min Lax+POST mitigation"? I see it mentioned above but it would be great to discuss how the mitigation should behave exactly.
URL is the spec language around the behavior. As a quick refresher: the goal is to allow unsafe http methods (commonly POST) to attach cookies that do not specify a attribute but are being treat as "lax by default". This behavior is intended for newly created cookies and so has a lifetime limit of up to 2 minutes. Let me know if you have any more specific questions.
We (NAME NAME NAME and I) discussed this at TPAC and came to the following suggestion: We think that browsers have to apply a compatibility measure here, and it could be including cookies on cross-site redirects if they’re younger than, for example, 2 minutes. We’ll collect metrics to get a better understanding of what that number should be. We will update "Lax-Allowing-Unsafe" in the spec to document that behavior, which would make Chromium compliant to that and Firefox could (AFAIU) ship a compliant version as well. We’ll continue to recommend "Lax-Allowing-Unsafe" as the default behavior in the spec. We’ll note that this is a compatibility mechanism that browsers may support or not support at their own discretion. It's not a behavior sites should opt into.
I believe the "same-site redirect chain consideration" change should be removed from RFC6265bis, with the intention of adding it back to RFC6265Tris. RFC6265bis contains a number of improvements over RFC6265 that are being stalled due to UAs being unable to implement "same-site redirect chain consideration" in a web compatible way. My efforts examining metrics collected by Chrome haven't yet offered much insight into how this issue could be solved and I have no idea how much longer it could take. Because no UAs (to my knowledge) have shipped "same-site redirect chain consideration" I don't believe reverting the language will have any practical effect and shouldn't weaken any active protections. But publishing RFC6265bis as a new spec will have a number of benefits, including security/privacy benefits for the web's users.
This seems like a reasonable, pragmatic step to me.
Technologies such as HTTP/2 will split the header into multiple fields. This PR modifies the spec to no longer expressly forbid this and instructs servers to be aware and capable of handling multiple incoming headers.
In the original 6265 as well as in the latest 6265bis draft, this paragraph exists: This is directly contradicted by RFC 7540 and then : I personally suspect that trying to split the header up into multiples is a recipe for disaster and interop problems even if done only over HTTP/2, but maybe I'm just a pessimist. Would it be sensible to maybe address this contradiction (better) in the bis document?
HTTP/3, repeats the HTTP/2 statement as well: Both these HTTP RFCs also clarify that: But still, that is for the receiving end and does not really restrict the sender when using HTTP/2 or HTTP/3.
I agree that the inconsistency is bad. That said, why do you believe that using multiple field instances can cause an interop problem?
I'm fairly sure Chromium does this, so if there were interop problems, we'd probably have noticed by now. :-) The phrasing is a little odd and probably could be improved. One resolution is to say this is an HPACK-specific encoding thing and not actually sending multiple fields. The full text from 9113 says: I.e. this field splitting starts and ends its life in HTTP/2.
A concern: Some servers have a maximum request header field size limit of around 8K. curl makes sure to never send a header longer than that as it risks getting a 400 back and basically blocking that particular request without it being very obvious to the user. This is a limit RFC6265(bis) does not mention but probably should because it is one of the more important ones. By splitting up the header into multiple ones, the total size of the sent cookies should probably still remain smaller than 8K since there is a risk that there is a h2/3=>h1 conversion done that will pass those cookies on in a single header and thus be affected by this limit. It would if HTTP/3 didn't have the same wording so it also applies there.
Because one RFC says we MUST NOT send them and another says we MAY.
I bet there is a server side or two out there that then will not appreciate getting multiple such header fields, perhaps because the h2/h3 special case is not taken care of. But this is just be being worried, I don't know for sure this is the case.
Agreed that such a limit should apply to the total here. I think that would follow from treating this as a funny HPACK encoding of a single field, rather than semantically sending multiple fields. That's not precisely how it's described today, but it results in the exact same behavior on the wire. I.e. we can still get the compression benefits of compressing individual cookies separately, and resolve the slightly awkward phrasing.
Safari started splitting Cookies in h2 and h3 a few years ago, it actually improved website compatibility where the h2 load balancer had a per-field size limit but the ultimate h1 origin did not.
Understood and agreed. So yes, that "MUST NOT" doesn't make any sense, and it's inconsistent with the base HTTP spec. Would be interesting to find out how that got there.
I can't recall the discussions about it on the http-state list back in the day (man, it's been over a decade already!) and I could not find any relevant threads when I casually searched the archives.
Changed from SHOULD NOT to MUST NOT between draft 09 and 10: https://author-URL
I think the wording is intended to be internal to HPACK/QPACK -- that is, there can only ever be one Cookie field as far as HTTP is concerned, but Cookie is special-cased to be split when encoded. To deal with the special case, any occurrence of multiple values gets coalesced. I don't see this as a contradiction.
Are there any remaining concerns before I close this issue? I agree with Mike's interpretation that this isn't a contradiction. The spec mandates that UAs generate a single header field which the server expects on the other end. I don't believe that another layer transparently muxing/demuxing this field is an issue.
I agree that Mike's interpretation is the sensible one to draw from this. I disagree that this is what the specs actually say in the written words.
I can see the potential for confusion here.