Martin Thomson

My impression is that there is little value in saving the round trip. Using a resource identity is the best way to integrate with HTTP semantics, and a client should...

How likely is it that you have a server that supports resumable upload, the 1xx doesn't make it back to the client, and a meaningful amount of data is successfully...

> if any amount of data is transferred because simply the act of starting a new upload [...] cannot always be safely retried Attempting to solve for both this robustness...

We had initially thought that no browser actions would be needed here, but I realize now two things work against that: 1. Fetch doesn't expose 1xx responses. 2. Maybe any...

I'm not entirely sure what I was thinking at the time, but I can try to reconstruct it... The goal of this design is to work seamlessly in those cases...

From my experience there are two simple cases in which you might care about preflights. In the first, you are happy that they exist, because you are unsure that you...

The harder to deploy thing is almost certainly a feature, for sure. I'd say that once software is in place, flipping the switch should be easy, it's the process you...

> I thought it was the origin... Over what period? A flag on the connection could be considered to apply to all requests made on that connection. I don't think...

Note that @mnot raised this specifically for *source* ports, whereas the blocklist in the spec exists for *destination* ports. It's really important to be clear on this point. I know...

Yep, it's not simple. It's even worse than that when you consider the effect of NAT on source ports. I think that IETF action is probably the best way to...