Am Donnerstag den, 21. MÃ¤rz 2002, um 20:16, schrieb Larry Masinter:
> I'm reviewing the HTTP spec and the Cache-Control: no-transform
> directive; RFC 2616 section 14.9.5.
>
> To prevent transformations of authored content, servers could
> respond, when the client is "authoring", with a no-transform.
That would set us back to sending Translate headers.
> But I'm less sure of the utility of the Cache-Control: no-transform
> request; does it mean "don't transform the request" or does
> it mean "don't transform the response?". And would it apply
> to an origin server as another way of saying a kind of "translate"?
Hmm, 2616 is only speaking of content (and Content- headers). The
examples are with server responses.
I think modifying client requests is a no-no. Otherwise I
hope Internet Explorer sets "no-transform" when I'm online
shopping...
> Note that authoring clients should be sensitive to
> Warning 214 (Transformation applied). At least, then
> there would be some belief that they wouldn't inadvertently
> try to let the user edit something that wasn't the original
> source.
Everyday you learn some new HTTP Headers...;)
> I'm not sure how a DAV server would know whether to supply
> a cache-control: no-transform if clients distinguish between
> the resource and its source by the "DAV:source" property.
Can a "source" resources (listed in some other resource's
DAV:source property) have own DAV:source properties?
Must a resource designated as "source" be editable (e.g. support
PUT) and will that PUT influence the content of its
derived resource? When?
I think we need clarification of the "source" concept. When
do resources have a "source" relation?
- ASP/JSP pages
- shtml
- executables, object files and source code
- resources derived from a "master" with stylesheets
- ...
Which of these examples do we want to provide a solution
for with DAV:source?
> (I was also wondering about the interaction between
> cache-control: no-transform and the vary header. A response
> with no-transform and one without no-transform are different.
> So if the decision to supply no-transform depends on a request
> header, then should the result Vary by that request header?
I'm not really a fan of new HTTP methods, but just for interest:
Wouldn't a new method like "EDIT" which retrieves the editable
content of a resource make our life easier? It could respond
with a Content-Location where a PUT can be applied...
//Stefan