jiebi/CodeConvo huggingface dataset:
Code change:
(in order of precedence): Since there is no way to distinguish a successfully completed, close- <del> delimited message from a partially received message interrupted by network failure, a server SHOULD generate encoding or length- delimited messages whenever possible.  The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0. </del> <ins> delimited response message from a partially received message interrupted by network failure, a server SHOULD generate encoding or length-delimited messages whenever possible.  The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0. </ins> A server MAY reject a request that contains a message body but not a

Related discussion:
text: Reading through the discussion, a couple of notes; We already talk about half closed connections on the server side in , so talking about them on the client side isn't prima facie out of scope. It might be helpful to explicitly note that requests are not delimited by half-close in . That's not a normative change, just a clarification, and it aligns with broad implementation. It would also satisfy the desire to document "client should not do this" at least in that case. It seems like the best we can do on the server side (in terms of interpreting FIN from the client) is to document that some servers assume it to be a loss of interest, but this may not be reliable in all cases, and should not be relied upon by clients.
^ PTAL
In 9.6 "tear down", after "If the server receives additional data from the client on a fully closed connection, such as another request that was sent by the client before receiving the server's response", I'd add "or the message body". The RST problem is far more visible with POST requests that servers reject due to authentication, redirects, lack of cookies etc, where servers are tempted to respond and immediately close without draining the entire request message. Regarding the questions above, I'm still seeing a few possible hints/workarounds for server implementers who really want to have good interoperability and good assurance that a tab was closed. One hint is to emit a "100-continue" interim response in response to a half-closed request if the request was made over HTTP/1.1. If the client is still there, it will have no effect. If the client has completely closed, this one will trigger a reset from the client which will be detected by the server. The other solution is to consider that if a client sent a request in HTTP/1.1 without "connection: close" and finally half-closed the request side, it is extremely unlikely to be a simple implementation and that it can be assumed with good confidence that the client really wants to abort request processing.
Hey Willy, Would something like this do the trick? I'm a bit wary of putting this in the spec, since it's so specific and advisory. What do others think?
I agree both with the text and your concern.
Code change:
(in order of precedence): Since there is no way to distinguish a successfully completed, close- <del> delimited message from a partially received message interrupted by network failure, a server SHOULD generate encoding or length- delimited messages whenever possible.  The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0. </del> <ins> delimited response message from a partially received message interrupted by network failure, a server SHOULD generate encoding or length-delimited messages whenever possible.  The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0. </ins> A server MAY reject a request that contains a message body but not a

Related discussion:
text: Maybe we can enforce the fact that it's absolutely not a spec and just a hint by saying "... a server that really needs to distinguish these cases could for example send a 100 (Continue) non-final response if it hasn't yet sent a final response". This way it's clearly worded as a hint to work around existing API limitations and to remind developers that determining whether a client closed a browser window is not rocket science over TCP.
I would implement something like a zero-byte chunk, or a small mount of dummy data (safe to the MIME type such as JSON), which could also help "keep-alive" a streaming response without introducing a non-standard C-T. If a server has already generated the C-L header, I would just let the request run to completion. Or are we concerned about proxies buffering the response body, because 100 will always reach the client immediately?
BTW, I actually plan to implement some sort of cancellation support soon for web frontends behind URL; and I could help report some data wrt the detection mechanism, with or without the app responding to the cancellation event.
You can't send a zero-byte chunk before headers (and even less data of course). The only other reasonably interoperable thing you could send before headers to probe the connection would be a CRLF since most agents will ignore them before a message. Another approach would be to start sending "HTTP/1.1" without the status yet (or just "HTTP" without even the version), but it can be trickier as it will require to remember that this part was already emitted. Now after the headers it's different, you're already sending response data so you don't care, you'll know very soon if the client is still there.
I was wrong. What I proposed (i.e. writing extra body bytes) only works for frameworks that generate headers immediately without waiting for applications to write any data (which might include errors but as application payload). Re: 100-continue response, I noticed that the following restriction stated in rfc2616 was removed from rfc7231. "An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation. " Curious what's the background for this change.
Code change:
(in order of precedence): Since there is no way to distinguish a successfully completed, close- <del> delimited message from a partially received message interrupted by network failure, a server SHOULD generate encoding or length- delimited messages whenever possible.  The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0. </del> <ins> delimited response message from a partially received message interrupted by network failure, a server SHOULD generate encoding or length-delimited messages whenever possible.  The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0. </ins> A server MAY reject a request that contains a message body but not a

Related discussion:
text: I suspect the reason was the prevision for new 1xx status codes, that just clients can remap to pure 100 when they don't know them. Note, I proposed 100 but any 1xx (except 101) would fit. For example we might instead send "102 Processing" (rfc2518), which could be even more suitable and possibly less confusing.
I could live with this. Will report back how frequently we are seeing FINs with a pending http/1.1 request on the client side. Yes.
Code change:
To request a replacement Txn-Token, the requester makes a Txn-Token Request as described in txn-token-request but includes the Txn-Token <del> to be replaced as the value of the "subject_token" parameter.  The "scope" value in the replacement request, if different from that in the original Txn-Token, MUST NOT increase the authorization surface beyond that of the original Txn-Token. </del> <ins> to be replaced as the value of the "subject_token" parameter and sets the "subject_token_type" parameter to the value "urn:ietf:params:oauth:token-type:txn_token".  The "scope" value in the replacement request, if different from that in the original Txn- Token, MUST NOT increase the authorization surface beyond that of the original Txn-Token. </ins> 7.5.3.

Related discussion:
text: Addresses issue - clarifying the value for when requesting a replacement Txn-Token
In : Does this assume that should be ? Should we call it out explicitly?
Yes, I think that makes sense.
Code change:
associated registry. Signers SHOULD include "@request-target" in the covered content <del> list list. </del> <ins> list. </ins> Signers SHOULD include a date stamp in some form, such as using the "date" header.  Alternatively, the "created" signature

Related discussion:
text: Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?
Code change:
(a.k.a., <del> ), selection of the best response representation (regardless of the status code) is performed by the user agent after receiving an initial response from the origin server that contains a list of resources for alternative representations. If the user agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to obtain a different form of representation for that response. Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated (possibly hypertext) menu. Note that the above refers to representations of the response, in general, not representations of the resource.  The alternative representations are only considered representations of the target resource if the response in which those alternatives are provided has the semantics of being a representation of the target resource (e.g., a response to a GET request) or has the semantics of providing links to alternative representations for the target resource (e.g., a response to a GET request). </del> <ins> ), selection of content (regardless of the status code) is performed by the user agent after receiving an initial response.  The mechanism for reactive negotiation might be as simple as a list of references to alternative representations. If the user agent is not satisfied by the initial response content, it can perform a GET request on one or more of the alternative resources to obtain a different representation.  Selection of such alternatives might be performed automatically (by the user agent) or manually (e.g., by the user selecting from a hypertext menu). </ins> A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive

Related discussion:
text: in Section 12.2 uses "representation of the response", which I can't find a definition for. I think this should be "representation data" or "representation data contained in the response".
Much simpler, thanks.This is fine, but "a preferred kind of content" doesn't read well.
Code change:
RFC6749 and PKCE RFC7663, to grant authorization to an Initiating Device (e.g., Smart TV or interactive whiteboard) using a mobile phone as the authenticating device.  This combination of FIDO2/ <del> WebAuthn and Authorization Code Flow with PKCE enables cross device </del> <ins> WebAuthn and Authorization Code Flow with PKCE enables cross-device </ins> authorization flows, without the risks posed by the Device Authorization Grant RFC8628. 5.2.4. The FIDO Cross-Device Authentication (CDA) flow provides the best <del> protection against attacks on the unauthenticated channel for cross </del> <ins> protection against attacks on the unauthenticated channel for cross- </ins> device flows.  It can be combined with OAuth 2.0 and OpenID Connect protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated

Related discussion:
text: See issue
Closing issue
Hyphenate all uses of cross device (e.g. cross-device).
Code change:
the same DID, so it is important for everyone to be able to immediately recognize by looking at the Envelope of a Signed Statements what Artifact it is referring to.  This information is <del> stored in the Feed header of the Envelope.  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed Statements under the same key. </del> <ins> stored in the Subject header of the Envelope.  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed Statements under the same key. </ins> 5.1.3. <del> Besides Issuer, Feed and kid, the only other mandatory metadata in a Signed Statement is the type of the Payload, indicated in the "cty" </del> <ins> Besides Issuer, Subject and kid, the only other mandatory metadata in a Signed Statement is the type of the Payload, indicated in the "cty" </ins> (content type) Envelope header.  However, this set of mandatory metadata is not sufficient to express many important Registration Policies.  For example, a Registry may only allow a Signed Statement

Related discussion:
text: A note from the We'll be iterating on this a bit more, to create some use cases and examples for how feeds help producers and consumers benefit from SCITT.
See: URL There are several problems with this definition. It conflates using aggregations over an header parameter, with the header parameter. It confuses how the TS uses the attribute with how the uses the attribute (same problem as above). Suggested changes: Registration policies only apply to the feed identifier, they do not apply to the feed resource. See URL regarding the Transparency Service exposing the Feed Resource.
LGTM!LGTM
Code change:
Digest Algorithm: sha Description: The SHA-1 algorithm RFC3174.  The output of this <del> algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </del> <ins> algorithm is encoded using base64 RFC4648.  This digest- algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.

Related discussion:
text: There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM
Code change:
disclosable claims MAY even appear within other Disclosures. The following examples illustrate some of the options an Issuer has. <del> It is up to the Issuer to decide which option to use, depending on, for example, the expected use cases for the SD-JWT, requirements for privacy, size considerations, or ecosystem requirements.  For more examples with nested structures, see example-simple_structured and example-complex-structured-sd-jwt. </del> <ins> It is up to the Issuer to decide which structure to use, depending on, for example, the expected use cases for the SD-JWT, requirements for privacy, size considerations, or ecosystem requirements.  For more examples with nested structures, see example-simple_structured and example-complex-structured-sd-jwt. </ins> The following input claim set is used as an example throughout this section: <del> Important: Throughout the examples in this document, line breaks had to be added to JSON strings and base64-encoded strings (as shown in the next example) to adhere to the 72 character limit for lines in RFCs and for readability.  JSON does not allow line breaks in strings. </del> <ins> Important: The following examples of the structures are non-normative and are not intended to represent all possible options.  They are also not meant to define or restrict how can be represented in an SD-JWT. Note: Throughout the examples in this document, line breaks had to be added to JSON strings and base64-encoded strings (as shown in the next example) to adhere to the 72 character limit for lines in RFCs and for readability.  JSON does not allow line breaks in strings. </ins> 5.7.1.

Related discussion:
text: In response to Issue : Changed some words to ensure that the examples are not understood as an exhaustive list of possible structures Added note on non-normativity of examples Removed the word Option in the section titles and the numbers to avoid the notion of an exhaustive list of options
Code change:
Intermediaries can consume and produce priority signals in a PRIORITY_UPDATE frame or Priority header field.  Sending a PRIORITY_UPDATE frame preserves the signal from the client, but <del> provides a signal that overrides for the next hop; see header-field- rationale.  Replacing or adding a Priority header field overrides any signal from a client and can affect prioritization for all subsequent recipients. </del> <ins> provides a signal that overrides that for the next hop; see header- field-rationale.  Replacing or adding a Priority header field overrides any signal from a client and can affect prioritization for all subsequent recipients. </ins> For both the Priority header field and the PRIORITY_UPDATE frame, the set of priority parameters is encoded as a Structured Fields

Related discussion:
text: I have trouble parsing this sentence, specifically around "a signal that overrides for the next hop". Overrides what? Is a word missing here, or can we restructure the sentence to be clearer?
Original context was a proposal from MT here URL So I think we are missing a that_, e.g. . I made to fix that that.
Thanks!
Code change:
thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E. <del> The parameters are included in the entity-body of the HTTP response using the "application/json" media type as defined by RFC7159.  The </del> <ins> The parameters are included in the payload of the HTTP response using the "application/json" media type as defined by RFC7159.  The </ins> parameters are serialized into a JSON structure by adding each parameter at the highest structure level.  Parameter names and string values are included as JSON strings.  Numerical values are included

Related discussion:
text: align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.
Code change:
followed by the new maximum size, represented as an integer with a 5-bit prefix (see integer.representation). <del> The new maximum size MUST be lower than or equal to the last value of the maximum size of the dynamic table.  A value that exceeds this </del> <ins> The new maximum size MUST be lower than or equal to the limit determined by the protocol using HPACK.  A value that exceeds this </ins> limit MUST be treated as a decoding error.  In HTTP/2, this limit is the last value of the SETTINGS_HEADER_TABLE_SIZE parameter (see HTTP2) received from the decoder and acknowledged by the encoder (see

Related discussion:
text: This is a minimal proposal for solving .
LGTM
Lgtm as well. On Mar 17, 2015 9:47 AM, "Martin Thomson" EMAIL wrote:
Code change:
digests (or whether to use them at all) is a trade-off between the size of the SD-JWT and the privacy of the End-User's data. <del> 9.3. </del> <ins> 9.4. </ins> Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user

Related discussion:
text: As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity
Code change:
offset of the incomplete upload by sending a "HEAD" request to the upload resource. <del> The request MUST NOT include an "Upload-Offset" or "Upload-Complete" header field.  The server MUST reject requests with either of these fields by responding with a "400 (Bad Request)" status code. </del> <ins> The request MUST NOT include an "Upload-Offset", "Upload-Complete", or "Upload-Length" header field.  The server MUST reject requests with either of these fields by responding with a "400 (Bad Request)" status code. </ins> If the server considers the upload resource to be active, it MUST respond with a "204 (No Content)" or "200 (OK)" status code.  The

Related discussion:
text: Closes URL A client can express its interest in digests using during upload creation. The server can then respond with after POST and PATCH requests to share its digest with the client. The client computes its digest as well during the upload and compares the digest to spot issues. The representation digest of an upload resource covers the entire bytes that have been uploaded so far (i.e. right until the upload offset). NAME NAME Is this in line with the semantics of RFC 9530?
NAME Need a week for the review :)
Preliminary feedback: I'd simplify the language/split text on multiple lines; Describe processing in separate subsections, e.g.
Thank you for the feedback, Roberto. I added subsections for representation and content digests in URL I think this division helps the reader and also makes sense since representation digests can cover the entire upload, while content digests only cover one request. Let me know if you think differently.
URL added some guidelines on how a client may include integrity fields to upload requests for protecting the integrity of a single request or the entire upload. However, this either requires the client to compute the digest upfront (before sending a request or starting the upload), or the use of request trailers, which is not very widespread and not always possible (e.g. the ). Instead of requiring the client to compute the digest upfront, the server and client could calculate the digests while the upload is ongoing. Once the upload is completed, the server can send its digest to the client in the response to the request that completed the upload. The client can then compare the server's digest to its computed value. If they don't match, it can raise an error to the end user and decide to not continue using the uploaded data. The client should indicate its interest in the server's digest when an upload is created, so the server is not required to compute the digest if the client has no interest. I am wondering if the from can be used for this. Can a client include in the first upload creation request, but the server delivers the digest potentially later in a response for a subsequent request? An upload may be spread across multiple requests.
Should also be supported? For multi request uploads, there's really no use to continue if request 3 of 100 got corrupted.