can Content-Range appear in a request?

[reschke]

No description provided.

[MikeBishop]

Hypothetically, you could be uploading a partial representation of an object, so I'm not sure it's worth prohibiting. However, I've not dealt with any systems that allow partial PUTs. Mostly you PUT (or POST) the blocks as individual resources, then make a final call with the blocklist to assemble the object from the existing blocks. Unless anyone has seen it in action, it's worth indicating it's not common practice.

Perhaps a note saying that the behavior is dependent on the method and isn't defined for any known methods?

[royfielding]

The essential problem is that it is not interoperable in general for PUT without private agreement between client and server. Furthermore, there is a risk of bypassing content filtering for security, etc.

I could see it being usable with a new method.

[mnot]

My understanding has always been that you couldn't have a partial request. We've discussed this extensively before; would need to dig up the references.

[mnot]

(it may have been in discussion of PATCH, which is the proper way to do this)

[mnot]

Proposal:

A server must ignore a Content-Range header field received with a request method which is unrecognized or for which Content-Range support is not defined. No request method in this specification is defined to support Content-Range.

... to align with the language used in Range.

[royfielding]

maybe

A server MUST ignore a Content-Range header field received in a request with a method for which Content-Range support is not defined. ...

since this case doesn't matter if the method is unrecognized.

[mnot]

Should we mention PUT's requirement to generate a 400 if C-R is present?

[ioggstream]

Sorry... I just overlooked this, which is related to the ongoing work with digest @LPardue.

My understanding is that with a new method, this could be possible.

[LPardue]

Fwiw my minor survey showed that most storage oriented services actually seem to offer some variant of request with Content-Range, see

https://lists.w3.org/Archives/Public/ietf-http-wg/2020OctDec/0285.html

[reschke]

But most of these use PUT, for which this is explicitly called out as "MUST NOT".

[ioggstream]

I'll propose a RESUME method + Content-Range for that.

[reschke]

I think the simplest possible approach would be PATCH with a payload format that just describes offset, length and payload. No need for a new method.

[MikeBishop]

But most of these use PUT, for which this is explicitly called out as "MUST NOT".

Which brings us back to the discussion about whether we're defining restrictions or describing usage, doesn't it? Lucas's survey demonstrates that PUT with Content-Range is widely used, even if currently prohibited.

[royfielding]

The existing restriction is that PUT means make this payload the current representation. There is no way to remove that restriction without breaking interop for PUT, which pre-existed Content-Range by several years. We are talking about a dozen private implementations of partial PUT versus a billion deployed servers that will gleefully ignore the Content-Range or store it with the new representation (because it starts with Content-*). The only reason this isn't obvious is because almost all Internet-facing HTTP servers disable PUT, so we are left with a few private servers that don't care about Internet standards.

[royfielding]

But if we look inside the firewall at internal servers that support WebDAV and other variants of HTTP PUT, they do not support the use of Content-Range to perform a partial PUT. They would be able to support a PATCH method.

[royfielding]

I just checked the code and it seems mod_dav has supported partial PUT on flat files since RFC2616.

[mnot]

This is a very big change at the last minute. At a minimum, it needs to be discussed on list.

I'm also not very happy documenting a new feature that admits it's not interoperable or backwards-compatible, based upon one implementation in the wild (so far).

IMO a much better way of doing this would be to slightly loosen the requirement to generate a 400 when PUT contains a content-range, saying that it can be allowed by an extension or an out-of-band arrangement. Then, if someone wants to, they can create a separate spec for partial PUT.

[royfielding]

Well, sure, but that's what the PR says. I don't see how removing the current requirement to generate 400 (which exists to preserve interop) is possible without documenting what should be done instead to preserve interop, even if that happens to be a "Hail Mary" pass more likely to be dropped than caught.

I have no idea if this matches any specific implementation. I'd give it around a 50% chance, as opposed to the 10% that I previously assumed. It definitely needs to be discussed on list, but it seems to match the general intent if we allow Content-Range to be used at all. This doesn't prevent anyone from publishing an update in the future.

In any case, I decided to propose it now since I did most of the arguing against this feature in the past.

[mnot]

I'm proposing that we just say something like:

An origin server that allows PUT on a given target resource SHOULD send a 400 (Bad Request) response to a PUT request that contains a Content-Range header field (Section 14.4), unless a protocol extension or out-of-band agreement allows it. Without such an agreement, the payload is likely to be partial content that has been mistakenly PUT as a full representation.

[reschke]

In the interest of getting the spec out, I slightly prefer Mark's proposal. That said, if we can get the description of partial PUT in (and that might be possible), I'm ok with that as well.

[ioggstream]

I think the current implementation landscape suggests us to be open about partial representation in requests (and that's what is relevant WRT Digest).

Which were the compelling reasons for forbidding PUT + Content-Range ?

[reschke]

@ioggstream - see #618 (comment)

[royfielding]

BTW, the Google API also uses a 308 Resume Incomplete status code to indicate a not-ready-yet error.

[reschke]

They promised to get rid of the 308 years ago; maybe it's just the documentation.

[mnot]

@reschke do you still aim for this spec to go to full Internet Standard?

[reschke]

Is this a trick question?

Yes, I think we should try. But then, we did add other new things, and also did a lot of re-org.