- From: Stefan Matsson <s.matsson@gmail.com>
- Date: Fri, 5 Sep 2025 10:35:50 +0200
- To: Willy Tarreau <w@1wt.eu>
- Cc: Tommy Pauly <tpauly@apple.com>, Working Group HTTP <ietf-http-wg@w3.org>
- Message-ID: <CAGx5t42H_B30bpYTR0a9wZMy90p4hs6DL6_WGge9ddi5ka5afw@mail.gmail.com>
Hi, Late on the ball (as usual) but anyhow... Some great feedback so far in this WGLC! I thought I could give some perspective on the spec based on my implementation in tusdotnet. I think for the most part this is a solid protocol that was easy to implement. The way of handling "reverse locks" (last request in wins) is a new way of thinking that works very well in this context. The same goes for the 104 response which makes it easy for the server to upgrade regular uploads seamlessly to the client. Where I have found issues during implementation have been mostly related to .NET and how it handles different things, like the absence of support for 1xx response, which I solved by some reflection magic (at least when running behind something other than IIS). The one thing that I would like to see is some better guidance on how to deal with the end result of the upload, i.e. how to handle processing errors or losing the final response. Section 11 speaks of using an "appropriate header" to send back information to the client which is fine I guess but it would probably be hard to write a generic client (such as fetch) if this header can be chosen by the server at will. In some discussions on Github there are mentions of doing a zero byte PATCH request to "re-trigger" the last response, which would probably also work, at least as long as the `Upload-Complete: ?1` header is not set by the server, at which point it is explicitly forbidden (4.4.2). Some clear guidance here would be appreciated even from a server perspective to understand how this feature should be used. Besides my minor concerns above I think this document is ready to proceed once the feedback from previous responders have been discussed. Best regards, Stefan Matsson On Sun, Aug 24, 2025 at 6:58 AM Willy Tarreau <w@1wt.eu> wrote: > 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 Monday, 8 September 2025 15:25:59 UTC