jiebi/CodeConvo huggingface dataset:
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: Often people who want to do this mix up the end of message and the end of connection and tend to believe that if the connection is not aborted, there will be no more opportunity to do it. But in fact if the client really aborts, the server will receive RST in response to some send() and will be able to detect the close. I would say that : half-closed (shutdown(SHUT_WR)) is a graceful shutdown (i.e. "nothing more to say"), signaled on the wire with a TCP FIN and detected on the server as read()==0 abort (close()) is a real connection abort (i.e. "stop sending this to me"), signaled on the wire with a TCP RST and detected on the server as send()==-1 The only case where you don't know is until you've started to send(), which explains why haproxy uses its option to decide what to do before receiving the server's response. I'm just realizing that we could even suggest to send a 100-continue in response to a half-closed connection to probe the connection!
What I've heard back from Microsoft folks with access to old emails is that we've seen half-close behavior from: .NET 2.0's HTTP implementation An IBM Java client, about which we have little additional detail Obviously, these are old clients with negligible share. However, that also illustrates the risk: old clients will not be updated to comply with a new spec.
Go's HTTP package uses EOF from clients to mean "the HTTP client is probably no longer interested in the server's response". We use it to notify callers of the HTTP server who've registered their interest in knowing when the HTTP client is gone (especially one reading a long-polled response, like Server-Sent Events). Notably, we want to know this immediately upon a FIN, without waiting for a write to fail. (We might not have anything to write for some time.) While we might ideally use OS-specific TCP stats kernel interfaces to distinguish FIN from RST, we support a dozen+ OSes and the basic interface we can rely on is EOF on FIN. There often isn't a better userspace API available to know the TCP state. I'd rather the HTTP spec say that clients should not half-close TCP connections, as some servers may interpret a half-closed connection as a client that's no longer interested in the response.
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: Go has a package that lets you do low-level networking-y things. Anybody porting low-level C could port to that. The concern for this bug is about Go's behavior, not its package.
Hi Brad! You must not resort to using the OS to distinguish between the two because you don't need to know that. As you say it's system-specific. And until you send anything you're not guaranteed to get an RST anyway. The problem you're facing is that you're acting as a proxy between the client and the application. You need a way to let the application know that the client indicated that it stops sending, and only the application can decide if it's an indication of end of transfer or of client abort. Sometimes the application will decide that both are equivalent and that's fine. Of course when you get a notification of error via an RST, it's pretty clear and unambigous. If I may suggest, "just" pass a shut_read info in one case that applications are free to interpret as aborts if they want, and an abort or close info when you're certain it's closed. But really any network-based application must be able to tell the difference between half-closed and full-closed otherwise it's deemed to either abusively close on regular half-close or ignore real closes sometimes. In practice people tend to see TCP as a bidirectional stream while it's in fact two independent unidirectional streams. The only link between the two are the ACK numbers passed along packets to confirm receipt. But FTP servers for example are well used to seing half-closed connections since the data channel can be half-closed during the whole transfer.
NAME Go's HTTP package has supported its API since 2013-05-13 and the means it's not going away. We can improve the implementation, but we can't pretend the problem doesn't exist and remove the feature. It came about because it was frequently requested. Authors of HTTP server handlers want to know when people close tabs in their browser, etc.
NAME OK that's perfect. Then it's more a matter of clarifying what each event means and what shortcuts may be taken with what impacts. In practice it's fine most of the time, it's just that it's important to be clear about what this really means.
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: For example it's fine to say "you can reasonably assume that a close notification indicates a closed tab and that you can abort an ongoing operation if your application is designed to work solely with a browser, but a more robust application should consider that it only indicates the client has nothing more to send and that the server must close just after sending the final response ; specifically, some scripts or API clients may induce a close event immediately after sending a request and while waiting for a response".
Discussed in Bangkok; we need to collect data about behaviour.
As an extra data point, both SwiftNIO and Netty treat receiving EOF on read as an indication the client is no longer interested in the response. We're definitely not happy with this: from our perspective, clients should be able to send FIN without us giving up on them. I'd be in favour of wording to disincentivise servers from doing what we (currently) do.
ietf104: significant interest in documenting somethinghere. at least "client should not do this" - hummed the question of discouraging the server from closing connection on rcpt of fin. a decent support for that pr.
There seems to be a really simple hack for differentiating FIN/RST. As NAME noted, a write will fail if a RST was received. This issue only applies to HTTP/1.1. Therefore: upon read-EOF, immediately write the "HTTP/1.1 " of the response line. If that write fails, you can safely abort generation of the rest of the response, because it was a RST. Or does this not work on certain platforms?
There are also various OS level options. Both epoll and kqueue can be used to distinguish FIN and RST, so it’s usually a matter of distinguishing the two cases in higher level APIs.
Good that this issue is still open :) Since the server always knows what works or not, writing a first-line header in response to FIN does allow most of the servers to detect aborted clients immediately. Maybe the spec can just clarify that FIN (half-close) should not be used by the server to cancel the request unless the server has a way to detect that the underlying TCP connection has been shutdown (i.e. the peer has gone away).
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: 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:
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: 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:
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: 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:
informational responses MUST NOT contain the "Location" header field. They MAY include the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload <del> progress.  The same restrictions on the "Upload-Offset" header field in informational responses from the upload creation (upload-creation) apply. </del> <ins> progress. </ins> The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a

Related discussion:
text: As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.
Code change:
13. <del> A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the "Transfer-Encoding" header field (RFC9112), applied, which modify the representation of uploaded data in a message.  For correct interoperability, the client and server must share the same logic when counting bytes for the upload offset.  From the client's perspective, the offset is counted after content coding but before transfer coding is applied.  From the server's perspective, the offset is counted after the content's transfer coding is reversed but before the content coding is reversed. </del> <ins> Since the codings listed in "Content-Encoding" are a characteristic of the representation (see HTTP), both the client and the server always compute the upload offset on the content coded data (that is, the representation data).  Moreover, the content codings are retained throughout the entire upload, meaning that the server is not required to decode the representation data to support resumable uploads.  See DIGEST-FIELDS for more information. </ins> 14. <ins> Unlike "Content-Encoding" (see HTTP), "Transfer-Encoding" (see RFC9112) is a property of the message, not of the representation. Moreover, transfer codings can be applied in transit (e.g., by proxies).  This means that a client does not have to consider the transfer codings to compute the upload offset, while a server is responsible for transfer decoding the message before computing the upload offset.  Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer-Encoding" header field. 15. </ins> The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS.

Related discussion:
text: Proposal for optimistic: The client needs to adapt to the header provided in the intermediate response and fail the request if the file is larger than the maximum allowed size. Proposal for Careful: The client can use the header provided in the to verify that the file is allowed to be uploaded before sending any data.Some editorial suggestions, but one big question: What is the material difference between the first and third strategy? Could these be the same strategy?
Code change:
If DEST is not an empty string and If DEST and REQUEST_DEST are not the same value, return FALSE <del> Let PATH be the value of "match" for the given dictionary. </del> <ins> Let BASEURL be the URL of the dictionary request. </ins> <del> Let SEARCH be the value of "match-search" for the given dictionary. </del> <ins> Let URL represent the URL of the outbound request being checked. </ins> <del> Let BASEURL be the request URL of the given dictionary. </del> <ins> If the {Origin} of BASEURL and the {Origin} of URL are not the same, return FALSE. </ins> <del> Let PATTERN be a URLPattern constructed by setting pathname=PATH, search=SEARCH, baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </del> <ins> Let MATCH be the value of "match" for the given dictionary. </ins> <del> LET URL represent the request URL being checked. </del> <ins> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </ins> <del> Return the result of running the URLPattern "match" algorithm (https://urlpattern.spec.whatwg.org/#match) </del> <ins> Return the result of running the "test" method of PATTERN with input=URL (https://urlpattern.spec.whatwg.org/#ref-for-dom- urlpattern-test) </ins> 2.2.3.

Related discussion:
text: This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by
Code change:
the initiating device to obtain a user identifier on the initiating device (e.g., through an input or selection mechanism) and if the Authorization Server can trigger an authorization on the <del> authorization device. </del> <ins> authorization device.  Do not use for same-device scenarios (e.g. if the initiating device and authorization device is the same device). </ins> 5.2.3.

Related discussion:
text: Added additional text making it clear that cross device flows should not be used for same device scenarios as suggested by Joseph Heenan (see )
From Joseph Heenan: URL I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Hi Pieter / Daniel / Filip It’s great to see this document moving forward. I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Also, in this text: "If FIDO2/WebAuthn support is not available, Channel Initiated Backchannel Authentication (CIBA) provides an alternative, provided that the underlying devices can receive push notifications.” It might be best to use a term other than ‘push notifications’ there or otherwise rewording this, as there are alternatives. e.g. I think there’s at least one CIBA implementation out there that can use email to notify the user of an authorization request. Thanks Joseph