jiebi/CodeConvo huggingface dataset:
Can you please factor the whitespace changes out into a separate PR?
Sorry, my editor did that without my knowledge. I didn't realize the draft was so messy to start with. Will do.
: This is good, but I think that the phrasing here could be more direct. "any semantic implied by the URI itself" - when you read suggests that you might infer something from a URI about what it does. However, I think that this underplays the key point. The point that should be made here is that a resource cannot decide to change the semantics of a method to suit its purposes (I guess unless it is willing to assume all responsibility for doing so, the usual caveat we apply here for things like request logging). Separately, the specific reference to 9.2.1 might be read to imply that safeness is special, but resources don't get to override the semantics of idempotent methods either (or any other well-defined properties of methods). So I would instead phrase this more directly and use the citation as an example only:
NAME can you PR that?
Sure.
though I do wonder if HPACK/QPACK needs to be explained as well, since the order in which messages are processed does impact their compression, but not their interpretation.
I would probably say that as the semantics are still stateless, this document probably doesn't need to say anything about that. But that's a weak preference only.
The change looks good to me. That said, it might indeed be good to mention the impact of header compression.
I clarified that this was about semantics. I'm hesitant to talk about header compression, as that's likely to just confuse the matter.
I thought that was already clear. We might need to mention HPACK/QPACK anyway because they are only stateful with regard to the in-transit encoding between peers, and thus deliver stateless messages at the HTTP layer. Or something.
Clarify if the request needs to be the 1st request after a connection is opened.
Is there a reason why you ask? Are there problems when it's not the 1st request?
I'm not aware of any such problem, and for example in haproxy we do support upgrades anywhere.
Just a question I had .. which I feel the spec may want to call it out, either 1st request only or no such restriction.
Nothing in HTTP depends on where a request is placed upon a connection, because it's a stateless protocol. see last paragraph (this is likely to move to soon, which is more appropriate. Should we spell this out more clearly there?
Probably, it never hurts to remind it.
I see the case for proxies to reuse and upgrade an existing connection to the server. Mentioning this will encourage correct server implementations.
I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.
Proposed update based on feedback in issue Open question for reviewers (and NAME whether we should allow both or only a single method, and if a single methods should we opt for the least common denominator (dpopjkt) or an authorization challenge endpoint specific one?
Commented over in URL that I think the single method of the DPoP proof header is sufficient and preferred.
I would tend to agree that we should stick with only the header option for DPoP.
I'm good with that. Will create a PR to reflect this.
NAME and NAME I made the changes. please review and feel free to merge if ready.
Because the client interacts directly with the Authorization Challenge Endpoint the authorization code binding can and probably should be done via the DPoP proof rather than the dpop_jkt parameter. This is similar to what but here you could probably get away with just using the DPoP proof.
That makes sense, we should do it the same way that's recommended for PAR.
NAME I was reading the rationale for requiring both the dpopjkt parameter and adding the DPoP header to the PAR request: URL It looks like the goal was to keep client libraries simple so that they don't need to distinguish between PAR or front channel flows. If we remove dpopjkt, do we make it harder for implementors of client libraries? Given that this is a new end-point (Authorization Challenge Endpoint) and a native client, we may not need to keep support for both and we can be more prescriptive, but I wonder if we might cause confusion for implementors as we have established dpopjkt as the least common denominator (the reason for allowing it to be used with PAR end points). Perhaps we should have similar guidance to DPoP on supporting both dpopjkt and allowing the DPoP Header to be added to the Authorization Challenge Response? I guess the question is really if we settle dpop_jkt as a the least common denominator in all DPoP impementations?
I think the in PAR was more about keeping the commonalty of authz request parameters and their treatment on both sides. Not so much about being a least common denominator. I think this Authorization Challenge Endpoint is different enough that just using the DPoP proof is the way to go.
would
It seems like it could be helpful to implementors, allowing them to quickly validate whether what they have is syntactically an SD-JWT or an SD-JWT with key binding. Something like:
The actual helpfulness of ABNF IMHO really depends on the readers familiarity with ABNF. I don't know that such familiarity is particularity prevalent. But, as long as it's correct, it doesn't hurt to include either. And while I'm not overly familiar with ABNF myself, I know enough to know that that isn't valid ABNF and doesn't quite correctly convey the SD-JWT constructs. I've endeavored to fix it up but am not 100% sure this is correct either: \ with a bit of help from https://author-URL
Looks good to me, thank you! Maybe a small improvement would be to introduce a name for disclosure?
That's a good improvement, thanks!
Looks good to me, and appears valid according to the .
(SD-JWT-KB part of the ABNF depends on another PR)
need to wait after is resolved to do a PR.
maybe add a KB-JWT line to be even more better? a la:
Not my religion, but happy to celebrate anyway.
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.
I'd like to discuss why we don't want to recommend supporting the spec for multiple first party apps? My thinking has been the protocol (whether in or out of scope) allows for a challenge/response method that the AS can control allowing it to support multiple apps at the same time. On the App side, this can be managed via an SDK that is used by all the first party apps. The AS needs to track which app versions have which capabilities to ensure the correct native experience is supported and if it's not possible to support the native experience then the AS asks the client to fall back to the web redirect experience.
Key point is that we don't want different user experiences implemented by the different apps. Add this topic in the Security Considerations section.
Also, if there are multiple 1st apps, can use OIDF Native SSO for Mobile Apps to create a better experience for the user
already stubbed some out in the draft, needs more expansion
Would we need a second profile to use this with OpenID Connect? How do we expect an AS that supports both OAuth and OIDC to implement this endpoint. Aaron - make sure this is possible without breaking anything. George - provide some guidance on what behaviour we want. Get AS behaviour consistent to simplify native implementations (no AS specific code needed). One idea - use examples from OIDC in a non-normative way. OmniAuth - maintains a list of providers their library supports. Aaron- 2 classes of implementors. (1) proprietary (2) those using OIDC
Copy language from PAR:
What profiling would we need to make to ensure that the new endpoint accepts any parameter the authorization end-point. The goal is to allow layering and use of other OAuth capabilities. Do we borrow from PAR?
Language from PAR: George: Some parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that is invalid in this use case.
Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)
This isn't TCP RTT based. For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
Rather than just PROTOCOLERROR, allow REFUSEDSTREAM. REFUSED_STREAM is a more lenient error. It allows clients to retry requests. Servers might also set the GOAWAY stream number to a lower value if they upgraded.
"5.1.2 Stream Concurrency" says about SETTINGSMAXCONCURRENT_STREAMS: "Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a HEADERS frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a stream error (Section 5.4.2)" But which stream error code should be used? Almost all other references to stream errors in the spec say "treated as a stream error of type XXX"
Also, if this is a stream error, what happens if the client has a CONTINUATION already in flight right behind the current-streams-violating HEADERS frame? The server would then return a stream error to the HEADERS frame, and then see the CONTINUATION frame that's not associated with an in-progress header block. I suppose a server should maintain enough state to remember that it sent a stream error on that stream ID and simply ignore any following CONTINUATION frames instead of returning a connection error?
The server knows that a continuation frame is coming as it is flagged in the HEADERS frame. Regardless, to ensure against corrupting the compression state, even if it is thrown out, all HEADERS/CONTINUATION data must go through the compression context unless you're closing the connection. This is even true for stream IDs that are not in a valid state (though I'd hope in those cases that the receiver would close the connection after immediately sending an error). , Brad Fitzpatrick EMAIL wrote:
NAME good point. My tests don't cover the case of a CONTINUATION having valuable compression context needed for future valid streams. I will update the test suite I'm building.
Discussed on-list; let's go with .
… might be allowed by consenting adults
My previous comment:
NAME you pushed back on MUST. My position is that our task is to define what's interoperable in HTTP, and bodies on GET clearly aren't. Using SHOULD here is a concession to a vocal minority who want to use the protocol in this way because they have pairwise agreements; I understand that if we use MUST here it'll be violated, but that puts the responsibility squarely and unambiguously on their shoulders. NAME point is valid -- if we use SHOULD, that ought (ha!) to be contextualised. To do so here, we'd need to write something like: The problem is that the message can still be handled by software that isn't party to or aware of that negotiation -- especially, intermediaries. So this isn't really something we should be encouraging. Hence, MUST.
I continue to disagree for the reasons you cited me above. Explaining the "SHOULD NOT" would work for me. If you want a change here, we might want to get those involved who actually use it in practice.
NAME please disambiguate 'above'.
The 'people who use it in practice' are not using HTTP -- they're building private protocols based upon it that don't interoperate with normal HTTP implementations. What they're doing breaks HTTP and HTTP implementations.
RFC 7231: "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." I disagree that makes an implementation sending content "not HTTP". You are pushing for a change here, and I really believe you need better arguments to support that. If the intent is to discourage things like that, I'm all in, but using "MUST NOT" is not likely to achieve that goal.
We got here because the 7231 language was ambiguous enough that people misinterpreted it, so we added a RFC2119 requirement. Our AD is rightly pointing out that if we use SHOULD, we need to contextualise it with when it's acceptable to violate the requirement. What text do you propose to perform that function?
"A client SHOULD NOT generate content in a GET request, unless support for content is negotiated (in or out of band)." sounds good to me
As I explained above, that won't work. Out-of-Band negotiation isn't available to intermediaries.
In-band negotiation is the SEARCH method (or whatever it ends up being called); it would be strange for the WG to allow other methods of negotiation when it's working on how to accommodate this properly. Also, while we place the requirement on the client here, realize that the impact here is really on the server -- it must not require a request to have a body in order to interoperate, because that precludes the client from using otherwise conformant HTTP implementations and infrastructure.
How so? Could you please clarify that? Are you saying that intermediaries are allowed to drop the payload? Where do we say that?
This discussion is not about future code, but about existing, deployed code which currently works for people, and which IMHO is not strictly forbidden by the existing spec. In past discussions, we agreed on strengthening how we discourage this, but a "MUST NOT" is very different from a "SHOULD NOT". For instance, do you expect HTTP libraries that currently support request bodies on GET to stop doing that, although there's production code relying on it?
No, I'm saying that the pressure we see to allow bodies on GET is being placed upon clients by servers who create services that use it, doing so because they read the current ambiguous language and find enough wiggle room to think it's allowed and a good idea. This is because the power dynamic between a client and server is often unbalanced, especially for APIs. It does not work in an interoperable fashion on the scale of the Internet - which is what we're documenting. Those are private agreements. The fact that it's not strictly forbidden is how we got here. Not any time soon, but those libraries aren't supporting HTTP in doing so; they're effectively supporting the creation of new, HTTP-derived protocols. How about:
Not following. It does work for some people (maybe because they use HTTPS or control the request path by other means). Saying that if something does not work "on the scale of the Internet" then it's not "HTTP" or shouldn't inform our spec does not work for me. If this was the case, we really would need to start removing many more pieces from the protocol. Also, telling libraries that they should stop supporting a use case that was allowed (with care) in RFC 2616 and 723x and which is used in practice doesn't look right to me.
We are past WG LC and IETF LC; if you really really want to change this normative requirement now (instead of explaining the SHOULD), then you should get support for that on the mailing list.
What I mean is that if you create a resource that uses a body on GET, you can't just use any HTTP implementation - you have to find one that does bodies on GET. Here, 'implementation' includes the framework in use, the server software, reverse proxies, CDNs, description languages, etc. Likewise on the client side; it's no longer a HTTP service, in that I can use any HTTP client; I have to find one that supports this extra constraint. Furthermore for proxies I might want to use, etc. Effectively, it's HTTP+GETBODY, not HTTP. It's not an extension, because it's not backwards-compatible. You say it's "used in practice", but as far as I see it, it's a few large services using their popularity / market power to convince people to break the protocol. That ignores the security and interoperability issues that this practice brings. Practically no one uses , but that doesn't matter. This does. If you can suggest a qualification for the SHOULD that doesn't compound the problem, I'm all for it. Absent that, I'll take it to the list.
Also, looking at the text in situ, I think the current second sentence doesn't need modification, leaving the proposal as:
... and since we've tried to align this language in HEAD and DELETE, the change would also be made there.
I really disagree with changing this. There are enough mentions on the net about "what happens if I send a body with a GET" that it's pretty sure we're going to declare a few in-house deployments non-compliant. For example we could imagine that some local deployments use a request body for an auth scheme. We could even more imagine this with H2. And with H2-to-H1 gateways, the risk of seeing a request body with a GET is even higher. The real problem with this spec is that from the very early days we only say how to emit but much less what to receive, and that many implementors on the receive path tend to take the server's "MUST NOT" for granted and ignore corner cases.
Marking a MUST NOT here would certainly re-open some smuggling issues just because some implementors would be less careful about this and would never check the presence of a content-length. So I definitely agree with Julian here, I'd rather keep the "SHOULD NOT unless negotiated by other means" at least to make sure everyone remains careful about this. Last, I'd rather not make GET such a special method after all the work we've done in 723x to try to uniformize processing for all of them! And as seen in a recent issue, at least both Apache and HAProxy deal fine with bodies in GET requests.
Maybe we split the difference -- there are certainly plenty of instances of "MUST NOT... unless..." in IETF specs.
I'm fine with this approach.
Am 16.07.2021 um 16:03 schrieb Mike Bishop: Hmmm. A "MUST NOT, unless..." really seems to be a "SHOULD NOT", no? Best regards, Julian
I think there's a difference, but it's subtle. "SHOULD NOT" implies that there are valid reasons you might choose to violate the spec, and describes what you should consider in making that choice. "MUST NOT unless" is an absolute prohibition outside of the described circumstance. I think Mark makes an excellent case for an absolute prohibition in the absence of prearranged support.
With that said, that will still declare all 723x-compliant gateways non-compliant, because they will emit this if they receive it. I'm really embarrassed by this last minute change considering the time spent on this during 723x before reaching that situation :-/
That is the very definition of a different protocol though. Why not just "MUST NOT" then?
It is HTTP. Is has not been forbidden in HTTP. It works in certain scenarios, and these are deployed. We can't undo that, even by "yelling". If we want to discourage people from doing this in new protocols, a "SHOULD NOT" wtih explanation is just right.
Right now you could use curl as the client, haproxy as the gateway and apache as the server and all of them would happily process this without a sweat because it properly respects the messaging. Regarding the semantics, it's up to the application making use of that to define it.