Re: PROPFIND vs. Accept: vs. variants
Geoffrey M Clemm <[email protected]> Thu, 21 Apr 2011 09:25:50 -0400
| Newsgroups | gmane.ietf.webdav |
|---|---|
| Message-ID | <OFAEAFA0D9.A0B72FF5-ON85257879.00495609-85257879.0049C6BA@us.ibm.com> |
--0__=0ABBF2EADFDAD0998f9e8a93df938690918c0ABBF2EADFDAD099 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable WRT the "related question", the first interpretation is correct. A server is allowed to associate multiple URLs with the same resource, = and in particular, may chose to do so to have a different "default representation" that is provided when the client requests a resource wi= th no Accept header. Cheers, Geoff [email protected] wrote on 04/20/2011 05:07:01 PM: > From: Wim Lewis <[email protected]> > > ... > A related question, in the context of rfc4918 section 5, is how > variant resources are modeled in terms of segment-to-resource > mapping. My initial understanding was that the 'foo' path segment > mapped to a single resource, whose content and properties varied > based on content negotiation. The fact that the resource didn't > correspond to a particular disk file was an implementation detail > and unimportant. > > The other interpretation is that the 'foo' segment maps to different > resources depending on content negotiation. This seems to be the > approach that Apache is taking, since in each case the PROPFIND > response indicates the more-canonical URL for the resource whose > properties are returned. rfc4918 states "it is illegal to have the > same path segment mapped to more than one resource", but it is only > mapped to one resource during any given request, so perhaps that is O= K.= --0__=0ABBF2EADFDAD0998f9e8a93df938690918c0ABBF2EADFDAD099 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <p><tt>WRT the "related question", the first interpretation i= s correct. </tt><br> <tt> </tt><br> <tt>A server is allowed to associate multiple URLs with the same resour= ce, and in particular, may chose to do so to have a different "def= ault representation" that is provided when the client requests a r= esource with no Accept header.</tt><br> <br> <tt>Cheers,</tt><br> <tt>Geoff</tt><br> <br> <tt>[email protected] wrote on 04/20/2011 05:07:01 PM:<br> <br> > From: Wim Lewis <[email protected]></tt><br> <tt>> <br> > ...<br> > A related question, in the context of rfc4918 section 5, is how <b= r> > variant resources are modeled in terms of segment-to-resource <br>= > mapping. My initial understanding was that the 'foo' path segment = <br> > mapped to a single resource, whose content and properties varied <= br> > based on content negotiation. The fact that the resource didn't <b= r> > correspond to a particular disk file was an implementation detail = <br> > and unimportant.<br> > <br> > The other interpretation is that the 'foo' segment maps to differe= nt<br> > resources depending on content negotiation. This seems to be the <= br> > approach that Apache is taking, since in each case the PROPFIND <b= r> > response indicates the more-canonical URL for the resource whose <= br> > properties are returned. rfc4918 states "it is illegal to hav= e the <br> > same path segment mapped to more than one resource", but it i= s only <br> > mapped to one resource during any given request, so perhaps that i= s OK.<br> </tt></body></html>= --0__=0ABBF2EADFDAD0998f9e8a93df938690918c0ABBF2EADFDAD099--