http-progress icon indicating copy to clipboard operation
http-progress copied to clipboard

submitted drafts

Open dret opened this issue 6 years ago • 9 comments

once these documents are stable enough to be submitted as drafts, please make sure to ping me. i'd love to add them to http://webconcepts.info/, but that probably only makes sense when there is a minimum of stability so that we can start advertising these concepts. thanks!

dret avatar Jun 23 '19 04:06 dret

Sure thing!

If you're watching the HTTP WG mailing list, I'll be shooting them an email too, once I think this is ready for multiple implementations.

On Sat, Jun 22, 2019, 21:38 Erik Wilde [email protected] wrote:

once these documents are stable enough to be submitted as drafts, please make sure to ping me. i'd love to add them to http://webconcepts.info/, but that probably only makes sense when there is a minimum of stability so that we can start advertising these concepts. thanks!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/awwright/http-progress/issues/1?email_source=notifications&email_token=AADK2DPKWZGPNWE33Z4PJWLP33443A5CNFSM4H2YCOH2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G3D6V2A, or mute the thread https://github.com/notifications/unsubscribe-auth/AADK2DOVGRISHRGMC6LJC2TP33443ANCNFSM4H2YCOHQ .

awwright avatar Jun 23 '19 04:06 awwright

On 2019-06-22 21:47, Austin Wright wrote:

If you're watching the HTTP WG mailing list, I'll be shooting them an email too, once I think this is ready for multiple implementations.

i think i am, but i'd still appreciate a note once these are drafts so that i can reference and add them. thanks!

dret avatar Jun 23 '19 04:06 dret

https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0066.html But I have not been able to submit Internet-Drafts yet since submissions are closed, but they will re-open when the IETF planetary starts. (As far as I understand, which isn't very much at all.)

awwright avatar Jul 14 '19 09:07 awwright

@dret I posted one of them as an I-D, please see https://datatracker.ietf.org/doc/draft-wright-http-partial-upload/

awwright avatar Dec 06 '19 08:12 awwright

thanks!

On 2019-12-06 09:22, Austin Wright wrote:

@dret https://github.com/dret I posted one of them as an I-D, please see https://datatracker.ietf.org/doc/draft-wright-http-partial-upload/

good work, but for web concepts this only makes sense once the concept has a stable identifier (i.e., you settle on a status code).

dret avatar Dec 06 '19 13:12 dret

Hi @awwright 🙂 I wonder what happened and why this proposal didn’t go any further?

andrewshadura avatar Mar 07 '22 12:03 andrewshadura

@andrewshadura Lack of time and interest, it's still on my radar. I can definitely prioritize it if there's interest! Help welcome!

awwright avatar Mar 07 '22 21:03 awwright

I’m considering your partial proposal for my application where I need to upload huge (5GB+) payloads through a proxy. It would certainly have helped if the proposal had details like the status code, or if it were accepted as an RFC, as that might have meant an existing implementation 🙂

andrewshadura avatar Mar 07 '22 21:03 andrewshadura

@andrewshadura Obviously I can't mint a status code; it would have to be published and submitted to the IANA for assignment. That could happen in short order if I submit it as an independent experiment.

My advice in the meantime would be to use multipart/byteranges as a PATCH media type. Although not formally described for use as a diff/patch, I don't think there's any ambiguity as to what that would actually happen. The only question is how do you handle a resource that's not complete yet? Maybe you use POST to create a resource. Your server returns 303 See Other redirect to a random URL. Do a PATCH to append to that resource. Then when you're all done, issue a MOVE on the resource with a Destination header. (This is effectively the same technique that text editors use: write a new temporary file, then mv() on top of the old file.)

While kind of unusual, that's 100% standardized (or at least unambiguous) behavior that would be expected by reading the specs as they currently exist, without needing to define new behavior.

What I'm aiming to do with this document is make support for this pattern discoverable by Web browsers, and also define handling for long-running operations, which is sort of related. None of these really seem to apply to you.

awwright avatar Mar 08 '22 01:03 awwright