jiebi/CodeConvo huggingface dataset:
Sounds good to me.
Might want to mention the scope of applicability for HTTP caching a bit more carefully, esp. with respect to other caches (esp. in browsers).
I think the best thing to do might be to change to something like "Relationship to Other Caches and History Lists" and expand accordingly.
Applications using HTTP often specify additional forms of caching. For example, Web browsers often have history mechanisms such as "Back" buttons that can be used to redisplay a representation retrieved earlier in a session. Likewise, some Web browsers implement caching of images and other assets within a page view; they may or may not honor HTTP caching semantics. The requirements in this specification do not necessarily apply to how applications use data after it is retrieved from a HTTP cache. That is, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime. This does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache-Control: no-store).
I've also added examples of the new behavior. This is an attempt to
URL shows an example of an origin server that contains English, French, and German versions of a resource, a cache that has cached the English and French versions, a request that asks for German or Spanish, and, I believe, permission in the spec for the cache to return the English version instead of asking the origin server for the German version. This happens because URL appends the first Variant to the list of requested languages even if the list of requested languages overlaps with the available variants. Is this a mistake in the algorithm, or intentional for some reason?
The language algorithm does that so that an origin can denote a 'default' language -- i.e., what to serve if there isn't any overlap between the client's preferences and what's available. For example, if a user configures their browser to send and the page is only available in English and French, there needs to be a way to say "send English by default." I don't know of any use case where someone would want to serve a hard error when the language doesn't match, but if that's in scope, we could figure something out. If you're looking for something more deterministic in caches (here, the distinction between "these ar the responses that are available and preferred" and "here's the default" is blurred), I'm interested. P.S. in that diff, the line with the comment "prefers French, will accept English(?)" seems wrong.
I think establishes the default language without confusing it with the responses that are available and preferred. I am also not interested in a hard error when the language doesn't match. And thanks, I've fixed the example.
I'm not entirely happy with the optionality of behaviour on the cache's part with those MAYs. The most explicit thing we could do would be to break this information out into a separate header (e.g., ), but sticking with the current syntax for the moment, what if we had special values that, when occurring in that first slot, indicate that the default should NOT match? E.g., where does the magic.
I'm personally happy with turning those MAYs into MUSTs. They're MAYs because that's what was in the older RFCs, but I agree that I don't like making things optional.
We should talk about whether the MOPS latency constraints make sense, or whether we should stop suffering and switch to something that's not about transport latency, but more about end-to-end workflow duration, which is what I think we're talking about in the "On Demand Media" section. But we can do that another day.
I think it's hard to really define latency for on demand for a whole host of reasons: The non-functional requirements for a system to process an on demand asset can vary dramatically. For example, it's common for news clips to have an SLA of clip duration to ingest, transcode, deliver, and be playable. Whereas for high resolution content, this stage of ingest and processing can take many multiples of duration and may be done hours/days in advance of its availability to playback. It's not really live, so the measurement of "latency" is a bit weird here. The latency between the origin storage serving the media to presentation on screen is, in general irrelevant from a playback perspective provided it doesn't stall out playback due to poor network conditions. Throughput and jitter have a greater affect.
Fix for
NAME PTAL
NAME PTAL
(moved to issue)
PACI packet is defined in RFC7798 ((URL, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet. In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically. We may ignore payload type 50 in H265 depacketizer.
Virtual interm slide is here: URL
Through the GFD (somewhat deprecated) and DD extensions?
yes. through GFD or DD depending on if it's perfectly layered according to spec.
URL NAME made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?
NAME I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.
Closing. At IETF 118, the proposed text was presented, and there were no objections.
Cookie attribute names are case insensitive, this PR adds a note saying as much.
The grammar implies that set-cookie attribute names are case insensitive (because ABNF strings are), and the parsing algorithms say that they're case-insensitive, but I suspect many people may not realise this, because they're so often seen in CamelCase. Could we add a small statement to the Set-Cookie syntax section pointing this out?
It's also worth having a variety of styles in the examples to illustrate this.
Header field-names are defined as tokens. This is an extremely permissive syntax, including characters that will cause confusion and likely break some senders/recipients. Most of the special characters allowed are not in the registry or seen "in the wild." Some research would be good to substantiate their use, but a starting point might be: There are a number of strategies we could take to the transition: Like / , mark some characters as "do not generate" but "should consume" Disallow registration of header fields with those characters, and discourage their use in unregistered headers If we have more confidence that they're not in use, just ignore headers containing those characters.
My opinion is that Apache httpd team would prefer to reduce the syntax to reduce the security issues.
Discussed in Montreal; interest in doing something, take to list.
I'm not sure why this is being considered. All browsers support headers such as . Changing that seems likely to break applications.
The restrictions exist to protect legacy server gateways (like CGI) that are far more restrictive than browsers need to be due to the terrible idea of passing names through env vars and command-lines.
in bkk: no real consensus, concern about compatibility. reconsider on impact of a case by cases
For the record, NGINX drops request header fields with names containing characters other than letters, digits, hyphens and optionally underscores (if configured using  directive). Unfortunately, virtually anything seems to be accepted and forwarded in the response headers.
Since I'm seeing the conversation moved from the WG to GH, I'm just pasting what I sent there for completeness. Right now haproxy only accepts : "-" / "" / "." / "+" / DIGIT / ALPHA / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "^" / "" / "|" / "~" i.e. everything matching a token. Quite honestly, seeing any character from this extra list in a field name would look extremely suspicious to me, and I'd rather get rid of them. As Roy mentioned, the restriction is to avoid trouble with CGIs doing : eval "hdrname=$value" Characters like backquote (), dollar ($), or pipe(|) have long been abused to attack servers...
Also I proposed that we could do something less extreme than blocking messages containing such header field names, we could recommend to simply drop these fields by default.
This will have no impact if they're here by accident. Then we can let the agents decide if they want to let them pass or not. Thus we could make the difference between "forbidden characters" (the historical ones) and "unusual characters" (those excluded by the new, more restrictive list).
Discussed in Bangkok, but no consensus on an approach.
ietf104: still seeking data for characters used in the wild. http archive mentioned as a possible source.
I'm sceptical about the "protect CGI servers" (and servers similar to those). We have 2020; shouldn't these all have their own protections by now?
Discussed in Basel; suggestion is to document "safe" characters in prose (for now), both below the ABNF and in the new header field recommendations.
Those CGI servers cannot protect themselves. The issue is that both hyphens and underscores are converted to underscores in CGI servers, so both and are converted to at the protocol level, and CGI servers cannot tell which HTTP header did it originate from, since that information is lost.
Hey Piotr, We chatted about that here and tend to agree -- will remove underscore and see how that goes down.
Well, to be clear, it is the HTTP server that invokes CGI that is creating the environment variables from the received header fields. That server is responsible for avoiding bad transformations, such as the underscore problem above. However, since we are just talking about the characters that are good practice, we can exclude underscores since they are not commonly used in field names.
This case seems easily avoidable by a subscriber, so the simplest option is to close the session.
Draft 04 currently doesn't mention about sending any response when the SUBSCRIBE_UPDATE is successful or when it fails even though the draft hints on possible failures The above suggests that an error should be sent to inform the client that it is making invalid subscription updates.
documents some other aspects of SUBSCRIBE_UPDATE that are underspecified.
Table 4 is missing SUBSCRIBEUPDATE, so there's no code for this message type. Section 6.5 doesn't say what to do when the update is malformed, in some way. SUBSCRIBEERROR? Is a bogus SUBSCRIBE_UPDATE ignored, or does it nuke the original subscribe?
One nit, but LGTMLGTM
I think we need a section summarizing what kind of claims SD-JWT can consist of... claims in SD-JWT can all be selectively disclosable claims, or can also include always-disclosed claims claim names in SD-JWT can all be blinded, or can include non-blinded claim names claim structure can be simple or complex and claims in the complex structure can be blinded/not-blinded and disclosable/not-disclosable same claim names can appear within multiple complex claim structures and can be blinded/not-blinded and disclosable/not-disclosable...
After carefully reviewing the Netflix advisories, it was clear that the problem was that implementations didn't read the original text. The TCP window reduction attack in CVE-2019-9517 was not mentioned, and it is a clever exploit. The rest were clearly already documented. I took the opportunity to restructure things a little bit. The first few CVEs were about causing the victim to enqueue a bunch of frames and then exploit the fact that this queuing was badly inefficient. Those got a list of their own. I purposefully left CVE-2019-9516 out. Though I am sad that people didn't free() after malloc(), this is pretty much just a systematized memory leak and I don't feel like calling that out in an RFC. I've cited the disclosure page, so I think we're covered there anyway.
The spec includes language on this, but it turned out that many implementations failed to properly safeguard themselves. Clearer descriptions of problems based on this experience would be good.
I don’t think it hurts to tighten the text up here and add more examples, at least so new implementations are better able to learn from past mistakes. However, we should probably keep in mind that this cannot possibly be an exhaustive list of exhaustion attacks.
This is the Netflix write-up, which might be a good reference: URL I can only imagine citing a markdown file on GitHub will raise eyebrows, but it's not a bad summary of issues.
One minor suggestion, otherwise I’m happy with the new text.
is already registered (URL). Do we need to register it again? I'm not sure what the guidance here is.
I believe we should add an IANA consideration to propose the registration of azc claim. A list of registered claims can be found here: URL
I believe we should add an IANA consideration and propose to register .
Thanks for this email and adding the issues to GitHub. I will update the spec shortly.
Implementation feedback. The "tid" claim clashes with a claim commonly used in AAD for the tenant ID. Perhaps we can use an alternative like idt, txi, txnid, txn_id or tti?
Discussed in the identity chaining call. Recommendation is to use the 'txn' claim name as defined in RFC 8417.
Add reference to SET add RFC 8417
Looks good to me
"This document defines the semantics of HTTP: its architecture, terminology, the "http" and "https" Uniform Resource Identifier (URI) schemes, core request methods, request header fields, response status codes, response header fields, and content negotiation." replace by just "fields"?
I think it's useful to retain the current text, because those phrases are more likely to be recognised by readers coming to the document.
No real opinion, but it should be rewritten anyway: This document defines the semantics shared by all versions of the Hypertext Transfer Protocol (HTTP), including its architecture, terminology, and core protocol elements, along with the "http" and "https" identifier schemes. It could go on from there to describe the core elements, and maybe the core features as well, but shrug.
half closed (client/server) is no longer used. :scheme header MUST include HTTP Request
NAME The fixes of the commit of 73dce91fcccecce7079d7ccf6294e80350d5ce19 were somehow lost after ea5abcf90460dc300b94eb27d82162f56a1dc526 . I'm not sure why it happened without conflicting. Please fix them by your hand.
Will do. It's easy enough to fix.
... and apparently some other stuff.
Should we recognise e.g., binary content in cookie values? If so, how?
Do you mind expanding on what you mean?
This is for the retrofit spec's cookie mapping](URL). Since many cookie's payloads are base64, it seems like it'd be beneficial to figure out a way to carry them as binary. I've been meaning to start a discussion with the cookie authors about this section of the spec generally to a) make sure it's a good idea and b) it's correct / doesn't cause problems. PTAL if you have time.
Maybe the right thing to do here is to introduce a new parameter that indicates the type of the value.
... except parameters aren't available on Cookie; just Set-Cookie. hmm.
Perhaps the most we can do is to say that the SF-cookie headers can have a value in any type, but they get mapped to the string value in "normal" headers. That way you can automatically convert SF-cookie to cookie, but not the other way around. The only alternative I see is to carry the type information in a separate header, which is not great.
That's
says: I think this should be:
Discussed in Basel. The current ABNF defines as a special value which only invokes the semantics when it's the entire field value; otherwise, it becomes a field name (since it's valid according to the field-name ABNF) and effectively gets ignored (since it's not going to be in normal requests). An alternative way of looking at it is to say that it's a special field name that, when it occurs anywhere in the Vary field value, it effectively turns off caching, no matter what the rest of the field value contains. Waiting for data to see what implementations do. Either way, this needs some examples in the spec, since it's so special.
See some results . It looks like all browser engines will turn off caching if `.
Duplicate of ? See also .
NAME shhh, we're trying to inflate our issue stats.
Adressing feedback in issue
NAME
Feedback from Dean Saxe on WGLC Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? URL
Fixed in Rifaat, I have a few minor nits in the doc, nothing of significant concern for WGLC. When describing the visuals documenting the flows, there is a step that includes “The user authenticates to the authorization server”. In each case this should include verbiage to indicate that this is only necessary if the user is unauthenticated, e.g. “If unauthenticated, the user authenticates to the authorization server…”. Specific sections include 3.1.1, 3.1.2, 4.1.1, 4.1.2 Section 3.1.3 the final sentence notes the authorization data may be delivered as a text message or via a mobile app. This is inconsistent with the methods mentioned in the first paragraph, which includes email and text messages. I suggest being clear that these are example mechanisms and not a full list of mechanisms by which codes can be delivered. Section 3.3.1 the first sentence should note that the QR code is associated with the particular service (Netflix, AppleTV, Disney+). Readers could assume that the QR codes originate from the TV manufacturer’s service alone as written. Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? Section 6.2.3 discusses FIDO CTAP 2.2. This document is still in review draft 01. We should note that the document is not final as of today. Section 6.2.3.5 could be softened a bit. The first sentence should include, “… and a suitable FIDO credential is not available on the consumption device.” In most patterns, this mechanism is used to bootstrap a new credential on the device, rather than using this mechanism for authN every time. Authors, if you have any questions please let me know.
HTTP 1.1 messaging is not normative replaced "message body" with a periphrases
Digest to be indepentent from http/1.1 (messaging) See URL
NAME iiuc the only MESSAGING-depending parts is: URL The spec references the term "message body" 3 times too, which is defined in MESSAGING. Do you think we should replace it? How would you do it?
trailers: you may want to reference URL message body: this might be "payload" (URL)
The original text here sort of implied that it was enough for an origin server to just send 2xx. That assumed that the request was for the origin server itself and elided a bunch of detail. This is shorter and clearer, I think.
I didn't intend anything here other than a clarification of what was written. I'm mostly guessing what was intended as I don't know what the original text truly intended to say. (I think that it was always possible to use CONNECT with a target of the origin server to do URL But I didn't want to highlight that here; it's a little bit of an odd thing to decide to do and so I wouldn't want to encourage it.)
I missed this from NAME but it's a point well-taken. Not defining this was sloppy.
This was buried inside which was closed so I'm opening a new issue. The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? It would really help if this draft defined every single field it declares.
The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? If in bytes, does it include or exclude the length of the Length field itself? Either way, I don't understand why Length is at least 2. Either it's possible for there to not be any field lines, in which case maybe it should be zero. And if there needs to be at least one field line, then (we should say so, and) the minimum number should be 3, because a field line is two lengths and at least one byte of field name.
To pile on here, the spec also says in one place and in another It's a little ambiguous but f the value also can't be zero-length, then the minimum should be 4? (by David's second interpretation)
NAME see
Yeah saw that after hitting the button. Didn't intend to derail
Thanks
Based on
The draft could benefit from some example use cases up front in the introduction.
Concise Use Case Description: Unprompted authentication, as defined here, serves use cases in which the provider of a service or capability wants only "those who know" to access it while all others are given no indication the service or capability exists. The conceptual model is that of a "speakeasy". For example, a company might offer remote employee access directly via its website, or access to limited special capabilities for specific employees. Members of less well-defined communities might acquire metered access to geography- or capability-specific resources by an entity whose user base is larger than the available resources can support. Unprompted authentication is also useful for cases where a service provider wants to distribute provisioning information to its resources without exposing the provisioning location to non-users. Edits/Additions welcome
Version 2: Unprompted authentication, as defined here, serves use cases in which the provider of a service or capability wants only "those who know" to access the service or capability while all others are given no indication the service or capability exists. "Knowing" is via an externally-defined mechanism by which user identifiers (required here) are distributed. The conceptual model is that of a "speakeasy". For example, a company might offer remote employee access to company services directly via its website, or offer access to limited special capabilities for specific employees, while making discovering (probing for) such capabilities difficult. Members of less well-defined communities might acquire access to geography- or capability-specific resources by an entity whose user base is larger than the available resources can support (via that entity metering the availability of user identifiers temporally or geographically). Unprompted authentication is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users.
Version 3: Unprompted authentication, as defined here, serves use cases in which a site wants to offer a service or capability only to "those who know" while all others are given no indication the service or capability exists. The conceptual model is that of a "speakeasy". "Knowing" is via an externally-defined mechanism by which user identifiers are distributed.
For example, a company might offer remote employee access to company services directly via its website using their employee ID, or offer access to limited special capabilities for specific employees, while making discovering (probing for) such capabilities difficult. Members of less well-defined communities might more ephemeral identifiers to acquire access to geography- or capability-specific resources, as issued by an entity whose user base is larger than the available resources can support (by that entity metering the availability of user identifiers temporally or geographically). Unprompted authentication is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users.
"security by obscurity", yes?