danielresnick

Thanks @LPardue - adding some more detail here based on some internal discussions: 1) Technically we can represent a hacky/limited form of chunk granularity via min-append-size=max-append-size=chunk_granularity*N. However this artifically constraints...

Agreed there are diminishing returns. I think that would be an acceptable alternative (assuming you mean specifying via a server advertised list as opposed to a hard-coded list in the...

I'm not an expert in this area but from what I gather it allows multiple simplifications/optimizations throughout our stack. It helps align writes to our underlying filesystem block size (which...

I had a look but wasn't able to find any concrete data on this unfortunately. I tend to think a non-linear range would be more client friendly/flexible though

Great point, I'd missed that the spec suggests not to retry unexpected 4xx responses. So yes I agree that within the current spec a 5xx response is most appropriate to...

Thanks for the clarification, @Acconut. That makes perfect sense. I agree that relying on a 5xx response feels like a necessary but semantically incorrect workaround under the current spec. A...

Got it, thanks @guoye-zhang. So if the client and server get out of sync due to a flaky connection, the client's retry would get a 409 Conflict and the upload...

Hey @guoye-zhang, thanks for the perspective. > Do you think it's important for clients to recover from that? Yes, absolutely. To me, this is the entire point of the protocol....

Thanks I've spun off into #3275 where I've tried to add some more detail about why I think spec complaint servers will inevitably need to return 409 Conflict responses.

Sent https://github.com/httpwg/http-extensions/pull/3320 to try to discuss a more concrete proposal. One thing I noticed in writing this is there is some ambiguity at the moment about whether clients need to...