jiebi/CodeConvo huggingface dataset:
We might need to figure out what data goes in the go away to given info that the clients enough info to do the right thing. Timeout can happen, and connections disappearing, and we need to sort out what impact that has but that is not the primary way to cause flow of media to change. Update: Key issue here is when the relays see the go away, do they drop the related forwarding state for the subscription, or do they just forward the update to the subscribers and wait for the subscribers to remove the subscription.
NAME NAME thanks for capturing the notes. I will work on set of small PRs to capture some of the items from the summary.
The point I was trying to clarify on the last call was that catalog already has a mechanism for a publisher to communicate to all subscribers that the track it has advertised as being available is no longer available. A clean FIN if you like. We can, as has been pointed out, create a control message which says the same thing. But then we have a weird asymmetry in which a publisher notifies clients of track availability through a catalog update but then uses control messages to do the reverse. For good design with clean encapsulation, we should seek symmetry in operation. We should either use control messages to advertise the availability/unavailability of tracks , or use catalogs, but not a hybrid of both. In my understanding of moq-transport, control messages have utility that is scoped to the current hop. They negotiate the format in which data will be exchanged on that hop and issue commands to subscribe/unsubscribe/announce etc. Those commands have no applicability to any other hops on the distribution chain. A catalog however is a contract between a publishers and all subscribers. Unlike control messages, it holds data that is not interpreted hop-by-hop and is intended for targets that can be many hops away. I think relays should be as simple as possible. In my conception, they should not understand whether tracks are being published or not. Their job is to move objects. Their view of the world is around objects and they do not need to understand what tracks are. While of course we can build all sorts of track intelligence in to relays, I think if we can build a base protocol which is agnostic to tracks, then it will be scalable and robust, and cleverness with tracks can evolve in the streaming formats without affecting deployed networks of relays.
and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.
NAME says: It's not very widely used and many implementations either don't support it at all or don't support it in a way that improves end-user performance. This sparked a lively discussion at URL
I’m open to dropping this, but I think the case needs to be be made for what the burden is. It’s one of the easiest protocol features to just ignore: send SETTINGSENABLEPUSH=0 and then you can remove all awareness of PUSH_PROMISE from your state machine altogether.
Crazy thought: what if we made part of HTTP/2, and then factored server push into an extension?
Or what if we minted a new ALPN () and flipped the default value?
Or left it as is, since it is used outside of browsers. The browsers have an API problem that has not been solved, and it is unlikely that push will be effective there (except as a competitor to inlining) until that changes.
I have no particular objection to flipping the default under a new ALPN. Factoring it out to an extension is harder, but not impossible -- it's pretty embedded in the state machine, but we might be able to abstract that away. Removing it entirely seems challenging for several reasons. The purely process one is that RFC 8030 requires Server Push, and removing a feature used by a Standards Track RFC presumably requires deprecating that other RFC.
I should note that my preferred outcome here is "do nothing". I'm just spitballing ideas.
Flipping the default if we mint a new alpn seems sensible based on the comments above. This would also align with HTTP/3. Moving it to an extension is probably more work than it's worth, I'll admit. I wasn't aware of RFC 8030. Is that an actively used RFC?
Push is being used outside of browsers (curl supports it, once implemented for a particular company that uses/used it pretty widely across the globe), although I suspect that outside of browsers we also have no real means of figuring out exactly how much or little. Saying "do it in extension" will probably equal killing it, but I also think that removing it from the spec is more work than its worth and just toggling the default seems like the best middle ground.
We may want to be a bit relaxed about flipping the default.
As the setting is client-only the default value never really exists on a connection: the client’s SETTINGS are the first frame it sends. The reason to flip the default is to save 6 bytes on all connections. This is not nothing, but it’s not a huge win either.
I agree that it's not worth changing anything here, except if we want to be sure to cause some confusion between implementations. The first frame sent is the one indicating support (or lack thereof) by the client. Maybe we should just add a paragraph in the PUSH section mentioning that 5 years after the relerase, PUSH has still got very low adoption among implementations and should not be assumed as a granted feature for protocols sitting on top of H2.
I think NAME suggestion of adding a note about deployment and not expecting wide support would be very helpful. My biggest concern with keeping it in the spec is that people will expect it's widely supported and its use is recommended for most use cases.
Feeling here seems to be supportive of no normative changes, but possibly some editorial additions clarifying the status of push. If you feel otherwise, please say so soon.
SGTM. FYI, Chrome is expected to drop support for HTTP/2 server push in the= near future and has never implemented push for HTTP/3.
NAME has it been announced somewhere? I can't find it.
Several popular web frameworks actively use Server Push including (mostly for assets) and (for API relations). Server Push is also (currently) supported by most browsers as well as by NGINX, Apache and Caddy. On the APIs field, , which aims to replace GraphQL-like document compounding is also gaining adoption, and rely on Server Push (even if it can fallback on preload Link headers and Early Hints too). I just published a benchmark showing how useful Server Push is for the specific use case of web APIs. Under certain conditions, relying on it can be 4x times faster than using compound documents: URL As pointed in martinthomson/http2v2, for these use cases, Server Push could be replaced by Early Hints or maybe by something using WebTransport, but these specs aren't currently implemented while Server Push is broadly available. Removing support for Server Push in Chrome will hurt all this use case. What's really missing with HTTP/2 Server Push is a way to prevent pushing resources already stored by the client.
could have been a solution, but the work on it looks stopped.
URL
NAME suggested calling out the current status: lack of support in browser APIs for push, pointy edges in the usage, and the limitations in the spread of its usage. I think this is a reasonable editorial change.
NAME to draft a document to encourage users to set the value to 0 by default and move on.
Discussed at Feb 2021 interim; intent to document concerns / caveats, recommend sending setting = 0. NAME to PR.
LGTMVery nice. Thanks Mark.
cc NAME since it closes your issue.
I believe this is now good to go, please approve or speak up if you disagree.
In there is a rather firm recommendation to erase priorities at servers that are served by coalescing intermediaries: This seems wrong to me. The Priority header field provides information about what the User Agent thinks of priority. This might be adjusted by intermediaries on the path, and it might not be globally consistent, but that does not mean the information should be discarded. Instead, I would prefer that we say that when an intermediary coalesces requests from multiple clients, servers need to be aware of that and account for that in their processing. The remainder of this text is fine in the sense that it identifies information the server can use to more fairly allocate resources to different requests, but - again - this is just information the server uses when making prioritization decisions. The model we operate on should not assume be that Priority is an instruction to the server, but that it provides the server (or intermediary) clues about how it might decide to allocate resources.
No one responded to this for a while, sorry. The text is mostly untouched but I did change the example to just . My read of this today, I'm concerned that the requirement is a bit specific. It's not clear if a server applying this would also discard any additional priority parameters. I don't know if NAME original point was along those lines or not, but I'll try to make a PR to address what I think needs fixing
We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager
There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.
"The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character)." Of these, only DIGIT is actually used.
also add associated IANA registration request and fix up formatting etc in other IANA bits see it live URL
There are 2 parts of the draft discussing the path to issuer metadata: and I do believe the latter is the currently intended /.well-known mechanism, whereas the first section was probably not updated and would result in to resolve metadata. I guess this was an oversight in ?
Thanks for catching the inconsistency NAME and I believe you are correct that the latter is currently the intended mechanism for .well-known.
We might also want to use something other than "user" in the example path. It's not wrong exactly but maybe unnecessarily misleading or confusing.
endeavors to fix this (and a few other little things)
lgtm
Sorry for noticing this so late. I don't think the security considerations of in retrofit work out. (Also CC NAME who is much better at web security than me.) If we introduce two ways to spell some field, we need to worry about whether this can allow various issues when sender and receiver don't agree on what's going on. The draft mostly leaves this to the future, but it does include some about this: This seems to put the onus on the sender, not the receiver. If you don't know the receiver accepts the alternate representation, you can't send it. It includes no corresponding receiver obligation, I guess on the assumption that if you see SF-Cookie, you can assume the sender meant it? I don't think that works. In a browser, the sender is a combination of browser logic (which has the final say) and JS (with a complex trust relationship). The browser logic specifies some which JS cannot set. Other HTTP systems have similar splits: an HTTP serving frontend may get fields from a CGI script or act as an intermediary, but it cannot allow the downstream code to specify fields like . These rules typically look like a blocklist with the default behavior to pass fields through. All this is to say, browsers won't let JS set the field directly, but setting is perfectly fine, up to CORS rules. A receiver may see that text and incorrectly assume that processing is fine, breaking some cookie invariants. Or vs , which will break some sites' CSRF processing. Beyond just blocklists, a retrofit-unaware HTTP cache that processes caching fields but passes through other fields will likely make a mess of the mapped caching fields. If we prefixed the names with , that would at least meet the browsers' rules, though I worry it'll still break other intermediaries. It's also a little unsatisfying of a fix. We could say that a receiver cannot process these either unless it's received some explicit negotiation that the sender knows about this. That's vague and unspecified, but probably would work, depending on what the intent is here. This is a bit handwaivy because I'm not sure what the use cases are here. But if we require explicit sender and receiver negotiation, it's unclear what we're getting out the parallel field names in the first place. It seems to me that's where all this risk comes from.
Giving alternate names interferes with pass-through logic across the pipeline. Maybe we can get a more robust story, inspired a bit by (I'm just assuming this is one of the main use cases here) is to say: The text representation of is what it is. If this part of the system uses the text form, use the existing syntax The structured field representation of is this mapped thing. If this part of the system uses structured fields, use that syntax At boundaries where forms change, convert. We need to be a bit careful about fallibility here, but perhaps: Conversion from text to other forms is allowed to fail, since you can just fallback to the text form. Conversion from other forms to text probably needs to be stricter? The difference between mapped and normal fields is the structured field and text representations don't directly align, so they need to be treated a bit special Like I said, this is handwaivy and definitely incomplete. But it feels to me like something in this might be more sound. It makes it more obvious we have to be sure what representation we're using at each layer and there's no risk of one side thinking something is a generic header and another thinking it's an alternative representation of a special header.
This seems like a plausible risk to me. I'm not as familiar with non-browser use cases, but I can certainly imagine confusion that would result from clients being able to create mismatches between and . I can imagine ways to deal with this in browsers (in addition to NAME suggestions, we could add as a , just as we've done for and ). It's unclear how helpful that would be for non-browser usecases.
Main nuisance with prefix is that, on the receiver side, you don't know a priori if the client is an updated browser, which knows about the prefix, or a preexisting browser which does not. I suppose you could do UA sniffing, but let's not design a system that requires UA sniffing to work if we can help it! :-)
That's fair. would be safe without a change to Fetch. Still, given my expectations about the current deployment of mapped fields, I think we could reasonably get ahead of them in the browser world. Not at all sure about the rest of the ecosystem...
I like the direction that if you've already negotiated support, you could just replace the legacy headers with their spiffy (SFfy?)
new equivalents using the same names, and if you haven't negotiated support then you have no business sending these variants and expecting them to work. Of course, that means this draft probably can't get away with "We don't define a way to negotiate this, but you do that."
I think we'd avoid needing "OUGHT TO" in that model. That model is more explicit that these are two incompatible representations of these fields. The negotiation requirements become more straightforward, I think: E.g. draft-nottingham-binary-structured-headers meets this requirement because you set a flag on the message, and gates usage on a setting. A hypothetical SF-based HTTP API would also meet this requirement because it's unambiguous that takes some in-memory structured field representation.
Hey David, Yes, I've been somewhat concerned about the potential issues in this area for a while. Minting new field names for the alternative forms was the initial approach, but I was half expecting someone to raise this issue :) One thing: No; the assumption is that a recipient sees SF-Cookie, they'll ignore it unless they've positively opted into it meaning something. Perhaps, as you point out, that should be more explicit -- e.g., say that these fields MUST NOT be processed unless the sender does [magic]. Making sure that evidence of [magic] is propagated properly may be tricky, though. I could also see removing the new field names. That should work for many contexts, although I suspect it might make handling the new forms difficult in some. Prefixing with doesn't seem very attractive to me.
Ah interesting. So I guess the middle option, "require explicit negotiation on the receiver" was actually the intended interpretation. That's not how I read the draft. It says "implementations are prohibited from generating such fields unless they have negotiated support for them with their peer" without saying anything about the recipient's responsibilities. So it sounds like, at minimum, we should update the draft. Getting that right in the presence of a chain of intermediaries is quite subtle however. Suppose we go A -> B -> C and both B and C support mapped fields, but A does not. B must be careful not to forward along a mapped field from A. E.g. it might decline to advertise mapped field support to C because A doesn't support it.
Or it might reject all mapped field names from A, on grounds that it must have been invalid. Moreover, "intermedaries" has to be intepreted very loosely. Every processing step in the entire HTTP pipeline needs to carefully manage these alternate names. This seems a disaster waiting to happen. I think I'm now convinced this is the only plausible option. Regarding "many contexts" and "some", do you have use cases in mind here? I saw draft-nottingham-binary-structured-headers, but I gather there are others? Something to keep in mind is that this draft intentionally punts figuring out the negotiation design to the future anyway. That means this is also the more flexible option. If we define , etc., now, we have permanently committed ourselves to this security problem. If we decline to define now, we can still choose. We can always define the parallel field names later, should something that needs them come up. (Of course, I'd raise the security problem again, but it'll be easier to reason about with a concrete use case! )
I guess this raises another question: how do we handle mapped field values that cannot be represented in the underlying text representation? Given how many intermediaries and intermediary-like constructs are involved in HTTP pipelines, and given how every HTTP system today uses the current syntax, I suspect mapped values that cannot be represented in the original syntax have to be treated as an error. Which means I think we need to go through the exercise of writing SF-to-text converters for each mapped field and then narrowing the allowed inputs until that converter is infallible.
It sounds like removing the field names is the best path forward. Yes, for those, the application using retrofit needs a fallback, just as it does for compatible fields. If that isn't obvious from the document, it should be clarified -- perhaps in a new 'Using Retrofit Fields' section.
I could very well be incorrect, but it sounds we want to have alternatives per each hop. Does that mean that these mappings would be best represented by ther per-hop pseudo headers that we have in H2 and H3? Not that I feel that doing so would be the best option, though.
Ooh yeah, per-hop is a good way to think about this! For pseudoheader vs. something else, I suspect it'll depend on use?
draft-nottingham-binary-structured-headers already has a flag, so it probably could just use the original names, though pseudoheader names would work too I suppose. The existing names has the minor benefit of being able to reuse the existing HPACK static table. Some sort of SF-based HTTP API like probably (?) doesn't want pseudoheaders in the API and can just use the original names. But I haven't put much thought into that. If one wanted to send them in their textual form in existing frames, we probably need pseudoheaders. Though I don't know if we really get much value out of defining that, over just using the existing syntax. shrug We can also punt this problem to documents that want to use this, if we're not sure yet. :-)
If you want to use an invalid field name, there are a lot more options than putting a ":" in the first byte. You need to negotiate that usage, but then you can do anything at all, including using that to signal lots of stuff. (If you want to avoid the extra byte, you can pack data into the high bit of each byte...)
I feel like punting is the right solution, unless we can come up with a convention that addresses the identified issues in all cases.
Not acting is a decision of a sort. But I'm not sure what that would concretely mean for retrofit? No prefix? Or just that we shouldn't worry yet about the effect this has on smuggling through WAFs and whatnot?
I think it means: No new header names; applications that use mapped fields need to define their own way to distinguish them A new section about these considerations
IIUC httpbis-semantics changes the field name registry, thus updating BCP 90 / RFC3684. Is that correct? Should httpbis-semantics mention that? NAME
"obsoletes": no, because BCP 90 is also for email. "updates": yes, I think so. NAME
Hm; I suppose so, given that it's taking some of 3684's turf away.
Now does that make SEMANTICS part of BCP90?
I'm inclined to say no -- it modifies the scope of BCP90 to exclude HTTP header fields. Worth discussing more broadly, though.