jiebi/CodeConvo huggingface dataset:
Code change:
only one audience is used to prevent Authorization Server B to abuse and present the token to Authorization Server C. <del> 2.3.7. </del> <ins> 2.3.6. </ins> The example belows shows a command the client invokes to perform token exchange at authorization server of domain A (https://a.org/

Related discussion:
text: parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details
Code change:
This document adds a new SETTINGS Parameter to those defined by RFC7540, Section 6.5.2. <del> The new parameter is ENABLE_CONNECT_PROTOCOL (type = 0x8).  The value of the parameter MUST be 0 or 1. </del> <ins> The new parameter name is SETTINGS_ENABLE_CONNECT_PROTOCOL.  The value of the parameter MUST be 0 or 1. </ins> <del> Upon receipt of ENABLE_CONNECT_PROTOCOL with a value of 1 a client MAY use the Extended CONNECT definition of this document when </del> <ins> Upon receipt of SETTINGS_ENABLE_CONNECT_PROTOCOL with a value of 1 a client MAY use the Extended CONNECT definition of this document when </ins> creating new streams.  Receipt of this parameter by a server does not have any impact. <del> A sender MUST NOT send a ENABLE_CONNECT_PROTOCOL parameter with the value of 0 after previously sending a value of 1. </del> <ins> A sender MUST NOT send a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter with the value of 0 after previously sending a value of 1. </ins> The use of a SETTINGS Parameter to opt-in to an otherwise incompatible protocol change is a use of "Extending HTTP/2" defined by Section 5.5 of RFC7540.  If a client were to use the provisions of the extended CONNECT method defined in this document without first <del> receiving a ENABLE_CONNECT_PROTOCOL parameter with the value of 1 it would be a protocol violation. </del> <ins> receiving a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter with the value of 1 it would be a protocol violation. </ins> 4.

Related discussion:
text: Add SETTINGS prefix to parameter name ENABLECONNECT_PROTOCOL. Fix one typo ("s/a entry/an entry/"). Remove "(type = 0x8)" which is ambigous (what is type?) and redundant with code listed in IANA Considerations section.
thanks
Code change:
only could look as follows: <del> The SD-JWT Release MAY contain further claims, for example, to ensure a binding to a concrete transaction (in the example the </del> <ins> The SD-JWT-R MAY contain further claims, for example, to ensure a binding to a concrete transaction (in the example the </ins> and claims). <del> If holder binding is desired, the SD-JWT Release is signed by the holder.  If no holder binding is to be used, the </del> <ins> If holder binding is desired, the SD-JWT-R is signed by the holder. If no holder binding is to be used, the </ins> algorithm is used, i.e., the document is not signed.

Related discussion:
text: addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR
Code change:
Optional padding.  Any amount of zero-valued bytes. All lengths and numeric values are encoded using the variable-length <del> integer encoding from QUIC. </del> <ins> integer encoding from QUIC.  Integer values do not need to be encoded on the minimum number of bytes necessary. </ins> 3.1.

Related discussion:
text: For the avoidance of doubt. This makes encoding easier if you don't care about wasting a few bytes.
The binary messages draft uses QUIC variable-length integers. Those allow encoding numbers multiple ways (for example 42 can be encoded minimally as 0x2A but also non-minimally as 0x402A). The draft should clarify whether using non-minimal encoding is allowed or not.
Thanks!
Code change:
it is not practical for the attacker to guess.  Each salt value MUST be unique. <del> 7.3. </del> <ins> 7.4. </ins> The length of the randomly-generated portion of the salt MUST be at least 128 bits. <del> 7.4. </del> <ins> 7.5. </ins> For the security of this scheme, the hash function is required to be preimage and collision resistant, i.e., it is infeasible to calculate

Related discussion:
text: Would like to go with salted hashes based approach, since there has been a lot of feedback that "simplicity (of salted hases approach) is a feature". However, acknowledging , adding a text to the security considerations explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT.
Code change:
the frontend and the BFF do not require any preflights, so there's no additional overhead. <ins> 6.1.3.3.3. Some technology stacks and frameworks have built-in CRSF protection using anti-forgery cookies.  This mechanism relies on a session- specific secret that is stored in a cookie, which can only be read by the legitimate frontend running in the domain associated with the cookie.  The frontend is expected to read the cookie and insert its value into the request, typically by adding a custom request header. The backend verifies the value in the cookie to the value provided by the frontend to identify legitimate requests.  When implemented correctly for all state changing requests, this mechanism effectively mitigates CSRF. Note that this mechanism is not necessarily recommended over the CORS approach.  However, if a framework offers built-in support for this mechanism, it can serve as a low-effort alternative to protect against CSRF. </ins> 6.1.3.4. In the BFF pattern, all OAuth responsibilities have been moved to the

Related discussion:
text: fixes URL
Thanks NAME I like it, I updated the PR
Because the UI and the backend APIs can be hosted from the same backend application, Anti-forgery tokens can also be used to protect against CSRF.
There are indeed various CSRF defenses that could be used in this architecture. The two options discussed in the current document explicitly focus on defenses that are part of the core web platform, and require minimal effort from the developer to implement. The use of anti-forgery cookies requires code on both the frontend and the backend to guarantee their effectiveness. Are there benefits to using anti-forgery cookies over samesite cookies/CORS that we're missing?
I thought it would be good to add this as it is per default supported in some tech stacks and so easy to use. People reading the doc might read it as only the mentioned ways protect against CSRF. Adding this would make the recommendations more complete. “Are there benefits to using anti-forgery cookies over samesite cookies/CORS that we're missing?” In my opinion, there are no benefits compared with the other two options, just another option. Samesite cookies/ anti-forgery cookies are also a viable option. If the used tech stack has this already supported per default, then there is less to do as a developer. This would make it an option.
NAME I am open to listing out this option as well for the scenario you mention. Do you have text you could suggest that captures this?
Hi NAME I'll write something Kind regards Damien
NAME NAME I created a PR with an initial draft. I don't think we should explain how it works because this is not the scope of this doc. kind regards Damien
Thanks for the suggestion NAME I believe it is important to explain why this addition is there, so I've taken a stab at rewording (see below). I have also removed some of the implementation details that are not necessarily relevant (e.g., the use of HTTPS). I also removed the note on encryption, since the value in the cookie is typically random, so there would be no need to encrypt the cookie. Let me know what you think.
Code change:
This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space.  The "HTTP/2 <del> Frame Type" registry operates under either of the RFC5226 for values between 0x00 and 0xef, with values between 0xf0 and 0xff being reserved for Experimental Use. </del> <ins> Frame Type" registry operates under either of the RFC8126 or RFC8126 policies. </ins> New entries in this registry require the following information:

Related discussion:
text: This is part of the fix for . This part removes the experimental range for frame types and settings. Also updates to use section references to RFC 8126, which replaces RFC 5226.
Nice clean change. No notes.
Code change:
server may reject JWTs with an "iat" claim value that is unreasonably far in the past. <del> The JWT MAY contain a "jti" (JWT ID) claim that provides a unique identifier for the token.  The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant. </del> The JWT MAY contain other claims. The JWT MUST be digitally signed using an asymmetric cryptographic

Related discussion:
text: The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.
Code change:
arise from receiving large messages, particularly those with large numbers of fields. <del> The format is designed to allow for minimal state when translating for use with HTTP proper.  However, producing a combined value for fields, which might be necessary for the "Cookie" field when translating this format (like HTTP/1.1 MESSAGING), can require the commitment of resources.  Implementations need to ensure that they aren't subject to resource exhaustion attack from a maliciously crafted message. </del> <ins> Implementations need to ensure that they aren't subject to resource exhaustion attack from a maliciously crafted message.  Overall, the format is designed to allow for minimal state when processing messages.  However, producing a combined field value (HTTP) for fields might require the commitment of resources.  In particular, combining might be necessary for the "Cookie" field when translating this format for use in other contexts, such as use in an API or translation to HTTP/1.1 MESSAGING, where the recipient of the field might not expect multiple values. </ins> 9.

Related discussion:
text: A combined "field value" is a term that HTTP defines, but we didn't link to that. Also, the structure of this paragraph was a little more terse than it needed to be.
Security Considerations state: but the Header and Trailer Field Lines section states: The same field name can be repeated in multiple field lines; see Section 5.2 of HTTP for the semantics of repeated field names and rules for combining values. This leaves me confused, why would it be necessary to produce a combined value if repeated field names are allowed?
Code change:
The "Early-Data" header field is included in requests that are received in early data. <del> The 4NN (Too Early) status code is defined for a server to </del> <ins> The 425 (Too Early) status code is defined for a server to </ins> indicate that a request could not be processed due to the consequences of a possible replay attack.

Related discussion:
text: (I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay
Code change:
It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols. <ins> Note that a TCP connection that is half-closed by the client does not delimit a request message, nor does it imply that the client is no longer interested in a response.  In general, transport signals cannot be relied upon to signal edge cases, since HTTP/1.1 is independent of transport. </ins> 9.7. TLS provides a facility for secure connection closure.  When a valid

Related discussion:
text: Historical note: HTTP 1.0 arguably specified the "abort request if the client half-closes" behaviour, see the last paragraph of URL, two pages down, just above URL This behaviour was implemented by several widely used HTTP servers; I worked on a firewall product at the time, and we had to take great care to make sure we handled TCP half-close correctly... The "arguably' is that RFC 1945 says "the closing of the connection by either or both parties", but sending a doesn't really "close" the connection - that requires either a or both ends -ing the other end's .
The HTTP RFCs say nothing about the expectations around half-closed TCP connections. In practice, I haven't seen any HTTP client in the wild send a request, and then send a FIN () while still waiting for the server's response. Because we haven't see any clients do that, as of Go 1.8, Go's HTTP server is starting to make assumptions that reading an EOF from the client means that the client is no longer interested in the response. (reading EOF being the closest portable approximation to "the client has gone away"). But in URL, a user reports that they have an internal HTTP client which does indeed make a half-closed TCP request. It would be nice if the HTTP RFCs provided guidance as to whether this is allowed or frowned upon. I would recommend that the RFC suggest that clients SHOULD NOT half-close their TCP connections while awaiting responses. Because nobody else does, empirically, and relying on reading EOF is a useful signal for servers. /cc NAME NAME
I've maintained a server in the past that received the same bug report. As a matter of compliance I decided the client was right - EOF is a way to delimit a message (they were using it to stream request bodies without chunking). But as a matter of practicality I didn't fix the bug because, as you indicate, ignoring EOF in practice means a lot of useless buffering ending in RST or timeouts.
NAME oh, interesting. And disgusting. I hadn't considered EOF being a means to end an HTTP/1.0 POST. Perhaps I can change Go to make an exception for HTTP/1.0 requests with request bodies.
Code change:
It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols. <ins> Note that a TCP connection that is half-closed by the client does not delimit a request message, nor does it imply that the client is no longer interested in a response.  In general, transport signals cannot be relied upon to signal edge cases, since HTTP/1.1 is independent of transport. </ins> 9.7. TLS provides a facility for secure connection closure.  When a valid

Related discussion:
text: NAME but NAME points out that RFC 1945 (HTTP 1/.0) says: So using a half-closing a TCP connection was never a valid way to signal the end of an entity body.
This is a pretty important question. Today, it's hard to spec out how cancellation works with REST. I suspect the proposed spec change will break some users. I wonder if it's possible to measure the impact with real traffic, from the server-side, e.g. the success rate of response completion after a half-close is received. I am happy to run some experiments ...
Here is a example of half-close connection in the wild, Livestatus. Livestatus is a broker for nagios. To use it via sockets you have to make the query, ex. and the close the write channel. After this, the Livestatus returns by the half-closed socket the results. Example in Python The important snippet is this, when closing the Write channel of the socket: Are there any workaround for golang? Source: https://mathias-URL
NAME Interesting. But is that HTTP? I see examples like the following on the web page. It does not even look like HTTP/0.9, though I am not sure what the proper syntax of 0.9 is.
It could be with unix socket or tcp socket. My fail I only read TCP, i did not see the repo is http :s. My bad, sorry, I came from another issue that was speaking about TCP without the http specification..
Hello, everyone! I would like to make a case for HTTP/1 disallowing half-closed TCP connections from the client. What I mean by that is that when an HTTP/1 client shuts down their writing end of the connection (when they send a TCP frame with the FIN flag), that the server can safely assume that the client lost interest in the unsent remainder of the response. On the other hand, if the server is required to support half-closed TCP connections from the client, in other words if the client is allowed to send a FIN after sending its request and it still expects to receive the response, then the server can only assume that the client lost interest when it receives an RST from the client.
Code change:
It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols. <ins> Note that a TCP connection that is half-closed by the client does not delimit a request message, nor does it imply that the client is no longer interested in a response.  In general, transport signals cannot be relied upon to signal edge cases, since HTTP/1.1 is independent of transport. </ins> 9.7. TLS provides a facility for secure connection closure.  When a valid

Related discussion:
text: To be able to treat an incoming FIN as an indication of the client's loss of interest has advantages for the server: The server can free up resources earlier, upon the reception of the FIN, rather than having to wait for an RST a network round-trip time after sending a data packet. The savings are most pronounced when dealing with responses that trickle information down slowly as a form of long polling. Some stateful firewalls (NAT) between the client and the server drop packets for connections for which they no longer have state, rather than sending back RSTs. The RSTs thus never make it to the server, the server continues trickling down information until the lack of ACKs causes its window to fill and eventually a write to time out. Server resources held on behalf of a client who lost interest are wasted resources. I believe that there would be little to no disadvantage to the client. Furthermore: HTTP/1.1 encourages the reuse of a TCP connection for a subsequent request. Request message bodies are framed using or : "The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field." ( URL ) TLS 1.0 explicitly precludes half-closing at its layer: When one end receives a "closenotify" alert, it is required that it "respond with a closenotify alert of its own and close down the connection immediately, discarding any pending writes." ( URL ) Thank you.
A half-close has never been an indication that the client isn't interested in the response. It only indicates that the client isn't going to send any future requests on that connection. Since HTTP/1.x is defined to be independent of the transport, I see no reason to specify half-close – what matters is that the request message be complete. A server is not obligated to send a response, regardless.
Yeah, but TCP is a pretty popular choice. I think it's worth clarifying what this part of TCP means for HTTP. This bug exists because implementations are disagreeing on what it means. We're looking to a spec for guidance.
It's pretty hopeless at this point. I propose we clarify that half-close means nothing to HTTP/1.x in this spec, i.e. it's not a cancellation.
Code change:
It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols. <ins> Note that a TCP connection that is half-closed by the client does not delimit a request message, nor does it imply that the client is no longer interested in a response.  In general, transport signals cannot be relied upon to signal edge cases, since HTTP/1.1 is independent of transport. </ins> 9.7. TLS provides a facility for secure connection closure.  When a valid

Related discussion:
text: If any http/1->http/2+ proxies send a rst stream when receiving a half-close from the client, it's a bug.
The problem with "clarifying it for TCP" is that HTTP runs on any transport with connection qualities and finding a word that means half-close for TCP doesn't always translate into some other transport or session-layer's meaning of half-close, but … I will try to find a way to do that when we get to the whole "what do we mean by a connection" rewrite in the semantics spec. In any case, regarding the original question: Go should not interpret an EOF on read as implying an EOF on close. Even if we don't see that as common in standard practice, there are probably thousands of deployed C applications that distinguish the two states; they won't work when some poor soul tries to port them to Go, and you'll be reliving this discussion on a regular basis. For example, IIRC, the first conversation I ever had with NAME (in 2000) was about using half-close to end requests in iCAP. It happens a lot more frequently in private hacks that are merely using the HTTP libraries for some other purpose.
in bkk: no strong consensus. mike bishop to see if he can identify clients that are using half close actively. agreed scope here is h1/tcp
I don't think there are any clients currently using this, but I think it would make sense to add guidance stating that half-close does not have any semantics, for all versions of HTTP. Having servers not kill half-closed connections may allow innovation down the line, and I don't think giving this guidance is risky
I've seen that quite a bit in field with monitoring scripts involving netcat, as well as data transfer tools. It's a bit less common nowadays since wget and curl are everywhere, but the usual stuff used to be this : host:$port | grep -q OK host:/d' > acl-URL In haproxy we don't do anything specific with half-close, we only rely on the end of message, unless the admin specifies "option abortonclose" in which case a half-closed client connection will be aborted if the server has not started to respond. Also there is no real value in killing half-closed connections.