jiebi/CodeConvo huggingface dataset:
Maybe a lot less users than I think are getting this cookie but given I’ve spotted it on 3 major news paper sites in 3 distinct countries, without having to look too far for these examples, makes me suspect that is not the case. says Facebook assets are being used on 2.38% of the most used 5.7 million sites and I’d guess they all come with some cookies for free. And that stat treats each of those 5.7 million sites equally when actual usage will be heavily skewed to the sites at the top end than the tail so usage will likely be more than that as top end sites are more likely to use Facebook advertising in my opinion. And again, I’m not concerned with this Facebook example - but more that it seems to suggest the 0.12% stat feels wrong. Or maybe it’s not being included since this empty cookie doesn’t seem to be sent in follow up requests, and that’s what that stat is measuring? If that’s the reason, and we’re comfortable with that explanation and the risks that entails (I am for what it’s worth), then that’s fine, but thought it worth asking the question.
As NAME notes above, we don't have statistics on cookie size generally; just aggregate numbers on header length. The "0.12% of users" statistic is the set of users who have ever sent an empty header (e.g. the only cookie they have for a given request is empty). If nameless/valueless cookies are set for other sites, they'll be serialized as , which we don't track specifically. I noted above that I'm less concerned about this case than I am about the "We used to get a header, but now we don't get anything at all!" case, but I'm honestly not terribly concerned about either given the existing diversity in the way browsers handle .
OK makes sense. Thanks for answering.
Yes, that's right.
The CFNetwork team approves of the change and is tracking the work in rdar://problem/58358759.
Given that, I'd suggest that we land something like URL along with the tests from https://chromium-URL Thanks! If you'd like to improve compatibility with IE and Firefox, you might consider representing these as nameless cookies instead of valueless cookie. You can observe the difference via test 0027: Set-Cookie: foo Set-Cookie: bar
This looks terrible, but it's the form that the RFC we cite uses (also, RFC 1323).
: We changed "Flow Control Performance" to "Flow-Control Performance" per the title of ("Flow-Control Principles"). Please let us know any concerns. Original: 5.2.3. Flow Control Performance Currently: 5.2.3. Flow-Control Performance
and 5.2.3: Should "bandwidth-delay product" be written as "bandwidth * delay product" per RFC 7323? Original: Note, however, that this can lead to suboptimal use of available network resources if flow control is enabled without knowledge of the bandwidth-delay product (see [RFC7323]). Even with full awareness of the current bandwidth-delay product, implementation of flow control can be difficult. ... If an endpoint cannot ensure that its peer always has available flow control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.
I think "bandwidth-delay product" is the standard representation of the term. It's not a term specific to this document but a broader term of art. I recommend not taking this suggestion.
Thanks, I hate it.
Addresses issue NAME
WCLC Feedback from Dean Saxe 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. URL
addressed in
lgtm 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.
Oh that makes more sense. Let's add this to the issue and see if others agree there.
NAME NAME you both approved when this PR set the value to 0 but I changed it. Please take another look.
if a Datagram object is delivered via FETCH (which doesn't really make sense, see and ), what Subgroup ID do I put in the FETCH object header? The only answers that make sense are zero, or the object ID.
I think the answer is getting datagrams via FETCH doesn't make much sense?
Agreed! The point of this issue is that there is an ambiguity in the spec unless we choose to close it via 588 or 599
I think we need to be able to fetch object that were originally delivered over datagram. Common use case is audio is over datagram and client got disconnected from the meeting for 10 seconds, rejoined, wants to get the missing 10 seconds and replay and 1.5x speed till it catches up then joins live meeting. I was sort of assuming subgroup would be zero for datagrams but I had not thought about using object ID. I would be concerned when doing that that object id can be large but size sub groups are limited to be pretty small so we could make them work with priorities. My question would be, does it every matter in anyway what the subgroup is for fetch ? If not, then zero seems fine.
Individual Comment: +1 for using zero It does if data that is FETCHed can later be subscribed to. Today it's possible because SUBSCRIBE allows Current Group (). If adding JOIN removes that (I think it should) then the protocol wouldn't have a direct use for subgroup. I wonder if there's a case of FETCHing a static asset to a re-broadcast publisher that would recreated the broadcast and want the subgroups though. I'm inclined to keep them in the FETCH stream wire format, at least for now.
The easiest way to think about this probably is, datagrams for a track have just on subgroup and thus its value is 0. I feel subgroup concept is important since it allows a publisher to control granularity of HOL blocking (based on subgroup size) support different priorities within a group I am not too sure of the requirement of fetched data to serve subscription. Even in JOIN flows, it is internally fetch + subscribe.
We have following cases: Case 1: Objects are sent as datagrams and cached with subgroup of 0 On Join, fetch will return all the objects until live edge on a single stream and then subscribe will get all the new objects as datagrams. Basically fetch flattens the priorities, original stream mapping (datagram here) and just returns objects from the cache. Case2: Objects are sent over streams and can have one or more subgroups. So when cached, objects can have different subgroupIds. On Join, fetch will return all the objects until live edge on a single stream and then subscribe will get all the new objects based on the subgroup mapping in one or more streams. Even here, fetch flattened the subgroups and priorities and just returns objects from the cache. What am i missing here ?
Maybe you want this comment on ? I think for now a PR with subgroup=0 should resolve this.
I don't have that strong a preference, but I would think having all Datagrams in a Group have the same subgroup ID would indicate I should be sending them over a single stream? Making the subgroup ID the same as the Object ID is more in keeping with the SubGroup == Stream transmission model.
Individual Comment: I previously +1 using zero but I'm convinced by Ian's argument to set it to the object ID. That may result in ever-so-slightly larger FETCH responses when there are more than 64 objects in a group, but I think that's in the noise.
I'm fine with this, since it resolves the issue, but I would think having all Datagrams in a Group have the same subgroup ID would indicate I should be sending them over a single stream? Making the subgroup ID the same as the Object ID is more in keeping with the SubGroup == Stream transmission model.
If it wasn't your thinking already, I'd like to suggest that the derived component be the singular instead. When canonicalizing individual query parameters, each component identifier references a single query parameter name/value pair. The use of singular feels more appropriate to me: In the rare case where there are multiple query parameters with the same name, each one's canonical representation is still referring to a single name/value pair, so the singular still feels more appropriate: When used in the list of covered components, we still include the parameter, so each component identifier is usually [1] referring to a single query parameter name/value pair: [1]: However, in that rare case of multiple query parameters having the same name, one instance of would cover all instances of that repeated query parameter named . Perhaps the plural does make more sense for this scenario. But if there must be a singular/plural mismatch somewhere, I'd rather see it in the more rare and exceptional case. So I would propose using the name instead of . In , I see that a recent addition implemented it as the singular . I wonder if drafters already had this change in mind or if it might have been an oversight that organically tended toward what feels more natural.
Thank you for bringing this up, I think this is a valid point. I don't think there's wide support for this derived component yet so now's a good time to change it for all the good reasons you mention.
Looks good to me, will leave for a beat to get feedback from others.
Thanks, editorial comments taken.
Whether this format is JWT or JWT-like, the considerations in the still apply. Please consider adding a claim. cc NAME
Explicit typing via the header can and should be done by specific applications or types of SD-JWT. But this SD-JWT draft is defining the general JWT-like construct and explicit typing of the generic thing isn't particularly useful or meaningful.
The The next draft will have a media type and structured suffix that can help with specific applications or types of SD-JWT doing explicit typing FWIW URL
I would be open to adding one sentence in the draft saying "applications of SD-JWT SHOULD be explicitly typed". I agree there cannot be only one type for all SD-JWTs.
I'm not quite sure where to add that one sentence. And a bit more context might be needed with it. I'll see what I can figure out. Maybe a small section like 3.11 in rfc8725. But (helpful) suggestions/ideas would be welcome in the meantime.
Add this sentence at the end of 5.1: The header parameter is RECOMMENDED, see Sec. 5.1.4 for more details. And as a new Sec. 5.1.4, "Explicit Typing": A commonly seen attack is for one kind of JWT to be confused for another. Both regular JWTs as well as SD-JWTs are vulnerable to confusion attacks. To prevent these attacks, it is RECOMMENDED to specify an explicit type by including the header parameter when the token is issued, and for Verifiers to check this value. The relevant token's content type can be used, e.g. , but often a more application-specific value is preferred. See Sec. 3.11 of RFC 8725 for more details.
Thanks NAME I took some inspiration from you words in creating PR .
merged PR to close this one
Thanks for preparing this! LGTM, just two small editorial comments.
I'm disappointed that RFC 6919 doesn't list "ARE EXPECTED TO".
Time for a bis?
In general, an unknown or new method can be handled by a resource by rejecting the request (with 406 for instance). However, some entities (intermediaries in particular) might be forced to engage with methods that are unknown to them. I couldn't find text in or Section 16.1 on this. However, the draft might benefit from advice on this. There are a few things that might be said, with reference to Section 9, which already says much of this: Intermediaries are expected to forward new methods. This enables the deployment of new methods. New methods might be safe, idempotent, or cacheable. Or they might not be. Actions taken need to consider this possibility and act accordingly. For instance, an intermediary that might be able to automatically retry a request cannot do so for an unknown method, which it does not know whether it is idempotent (9.2) or a cache can't cache a response unless the method is known to be cacheable (9.3).
PTAL. I don't think your second bullet is actionable; that's already clear in 16.1, and intermediaries aren't required to do any of those things.
In Section 7.3.3 (as noted by ) If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order.
This was already implied, but it does read better if we close the loop on routing by sending the request message with the identified request target.
Simplifies references to sha algorithms pointing to RFC 6234 instead of FIPS180 documents.
NAME ping :)
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
A private cache that can be manipulated so that it mistakenly creates a cache entry might not have the reach of a shared cache, but it can still be a problem. Cache poisoning occurs when a cache can be written to by an entity other than the one that the cache would normally recognize as being authorized to write to it. Take the websocket poisoning where a cache misread a websocket stream as HTTP queries and established cached records under arbitrary origins. This would allow for poisoning of entries normally not controlled by the host that was using the websocket. Even though that might have been a single user affected by the poisoning, the effect was serious enough and motivated the inclusion of masking in websocket.
Simple :)
Related mailing list thread: URL
these changes make sense to me
As part of , I would like to consider the removal of Consumer and consumer from this specification if we are not going to define it. It is a generalized term and I would rather expend work group time on trying to tailor an appropriate custom definition of it. I will likely post this issue to the mailing list and cross-reference that thread here and leave this issue for review for a week to solicit feedback. Related mailing list thread: URL
I do think Producer and Consumer is a good generic concept, with more clearly defined roles as Relying Party, Verifier, and Auditor, however, I'd support replacing Consumer with Relying Party or Verifier.
But we do not define them nor cite references that do. From a formality and procedures perspective in IETF, is that OK? Thanks for the feedback.
LGTM with some comments to accept/reject Hello, I have been reviewing the specification and there are usages of Consumer(s) as a specific term to be defined in the draft and consume/consumer(s) generically. The use of the term consumer is ill-defined and I would support not consuming time ahead of 119 defining it. Therefore, I am proposing that we remove the capitalized term and some generic usage of it for clarity. I welcome feedback on the pull request to alter or critique specific, individual changes (207), the issue to track the work for more general discussion (206), or in the form of replies in this thread on the mailing list. URL URL If I do not hear back in one week and there is no objection in the pull request, the issue, or mailing list, I will follow up and ask the authors to merge (if it has not been merged already). Thanks in advance for your review and any feedback you provide. Thanks, A.J.
The text in the document says: The Media Type Designated Experts' suggested to make that stronger, and have the following note on the : Let's agree on either "discouraged" or "prohibited", and align the text in the document and in the IANA registry note.
I believe what the IANA registry says is good, so what's left to do is to align our spec text with that. My understanding is that no new text in the IANA Considerations is needed, as the change to the registry already happened.
If we agree to add the reference to this RFC in the IANA note, once the RFC is published, I can ask IANA to do that.
Good point. We could add that to the IANA Considerations. Should I?
I think that would make sense. Let's hear from others.
The text on doesn't assign any behaviours to roles; it just passively states that http(s) URIs 'are' normalised and compared. This leads to some confusion about what roles are responsible for normalising. E.g., can a server consider and as two different target URIs? I think we all agree on the answer to that, but it isn't clearly stated in the specs AFAICT.
I'm not sure about that example (as a browser would never emit the latter), but they can certainly rely on some of the other variants and have been known to do so.
We currently just point to URL - so "path segment normalization" is something that may or may not happen, depending on who's doing the comparison. My answer would be "a server could do that, but it would be stupid". What's your take?
I agree with your answer, but think we should say something about it -- perhaps going as far as saying a server should/must not do that (as it's not interoperable).
Security is probably a stronger reason not to allow in request targets. Another reason that specific example, as opposed to '+' vs '%20', might be a bad idea.
see also URL
I think the comment is more confusing than the spec. The request target is whatever is provided by the client. If the server responds to the second example target with a 301/302 to the first, then it does consider them to be two different target URIs for the same resource. In practice, that is the best way to respond because it forces the client to change its own copy of the target URI before it makes the "right" request. IIRC, that what we do in Apache httpd. This type of response is not canonicalization -- it's reasonable handling of an unsafe target without breaking the intended request. We might call that responsible handling after the client fails to canonicalize a reference, but keep in mind that a ".." path segment only has meaning for relative references (not references that are already in absolute form). In any case, a client is not required to canonicalize beyond resolving of relative form to absolute form. Some other servers might want to respond with 403 (e.g., an authoring server responding to a link checker). That's okay too.
On the face of it, that conflicts with : Regardless, the question is whether we give any advice about servers considering these to be genuinely separate resources (putting aside corrective actions, as you illustrate), as it's not practically interoperable with most HTTP implementations. Even something in the normalisation section to the effect of:
There's clearly no consensus whether the current relevant specs (RFC 3986 and RFC 7230) allow it or not. This is indeed an obscure case, modern browsers don't request such URIs (not even programatically, from content scripts), neither does cURL with default options. But it should still be settled, for the sake of implementors of web servers and other backend tools, frameworks and authoring tools which help with IA by emitting appropriate server configuration (the question being whether they should allow, possibly with a discouraging message, to create different resources at such URIs, or even assume, given some site not created in them, that they must be the same) and also for defensive coders who believe, as Sir Tim does, that cool URIs don't change, and want to tightly control the set of URIs they respond to with representations of resources and thus admit that the URI is valid – identifies some resource. (I do. Therefore I forbid (default to 404 if they're encountered) trailing slashes, empty path segments, query strings containing only a question mark and so on, except when they are after explicit consideration added to a whitelist.) For all the reasons above I ask you to either declare request with dot segments in targets invalid (some handling may and probably should be defined, but if a client fails to conform to standards by sending malformed requests and gets inconsistent responses, so be it, some bets may be off, the semantics is preserved on the condition of conformance) or specify (MUST level) that the URIs are equivalent (and in thas case it's the servers which are non-conforming if they serve different resources at them). There are also purely practical reasons to do either of the two (as opposed to a SHOULD contemplated in some comments above). Being an uncommon case, it presents a problem for implementations, causing numerous bugs, and confusion (around bugs or otherwise) even among knowledgeable people. Cf.