- From: Willy Tarreau <w@1wt.eu>
- Date: Sun, 24 Aug 2025 06:54:42 +0200
- To: Tommy Pauly <tpauly@apple.com>
- Cc: Working Group HTTP <ietf-http-wg@w3.org>
Hi, Minor details from me, since Mike already reported a lot of things. I was initially confused by the first diagram in 3.1: Client Server | | | POST /project/123/files | | Upload-Complete: ?1 | |------------------------------------------->| | | | | Reserve resources | | for upload | |-----------------. | | | | |<----------------' | | | 104 Upload Resumption Supported | | Location: /uploads/abc | |<-------------------------------------------| | | X--------------Flow Interrupted--------------X Which I've read as: - client sends POST with headers - server returns 104 - client the possibly uploads data - transfer is interrupted As an intermediary implemented it worried me that we'd have a new header that would cause uploads to wait for an interim response. When reading the rest I figured it does not make sense and is just my incorrect interpretation of the diagram. But it also means that others could possibly implement it like this (especially clients which could then wait for the 104 before sending data). I don't know how we could fix the diagram. Maybe adding an arrow from the client to the server in the middle, like this: Client Server | | | POST /project/123/files | | Upload-Complete: ?1 | |------------------------------------------->| | body | |------------------------------------------->| Reserve resources | | for upload | |-----------------. | | | | |<----------------' | | | 104 Upload Resumption Supported | | Location: /uploads/abc | |<-------------------------------------------| | | X--------------Flow Interrupted--------------X At the moment that's about all from me (I've already added minor comments in a few issues about GET/HEAD and status codes, nothing that deserves discussing here). Regards, Willy
Received on Sunday, 24 August 2025 04:54:52 UTC