Subject: PaceSimpleResourcePosting and PUT

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 02 Jul 2004 18:55:44 +0200

PaceSimpleResourcePosting says:

   If a client has a hard requirement to control the URIs of the
   resources it uploads, WebDAV is probably the answer.

Why can't PUT be used with Atom? I assume this will be WebDAV supportive,  
but yet defined in the Atom specification. I think  
PaceSimpleResourcePosting should define a model for both POST and PUT. I  
at least can't see why it shouldn't.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: [email-masked] (John Panzer)
Date: Fri, 02 Jul 2004 10:14:39 -0700

Asbjørn Ulsberg wrote:

> Why can't PUT be used with Atom? I assume this will be WebDAV 
> supportive,  but yet defined in the Atom specification. I think  
> PaceSimpleResourcePosting should define a model for both POST and PUT. 
> I  at least can't see why it shouldn't.
>
I like PUT and DELETE too.  I didn't put them into 
PaceSimpleResourcePosting because I didn't think they were necessary and 
they need some more work to be properly defined.  I'm frankly really 
lazy and want someone else to do the work.  Asbjørn, would you like to 
volunteer? :^)

Here are some of the questions I'd raise about PUT and DELETE:

o These apply to the resource itself.  Can all Atom servers support PUT 
and DELETE on resources?  This is a serious question -- some people have 
said that they are restricted to CGI scripts and cannot modify their 
servers; we're talking about workarounds for passing authentication 
information to CGI scripts because of this.  So my first question is, is 
this supportable by all Atom-enabled servers?

o Not all users can PUT and DELETE all resources (consider access 
controls, shared blogs, etc.).  So you need a way to query as to whether 
you can perform an operation.  The Allowed: and Public: response headers 
(http://www.w3.org/Protocols/HTTP/Object_Headers.html#z6) seem like the 
natural way to do this and I believe this is compatible with WebDAV.  
For example, Allowed: GET HEAD PUT DELETE means that you, the user 
making the HEAD request, can perform a PUT to the resource.  Is this 
supportable by all Atom-enabled servers?

o Do we want to ensure that whatever Atom does in this area is "upward 
compatible" with WebDAV?  (I think this is the consensus, but I don't 
know if anyone has looked at the details for things like PUT and DELETE.)

o Is PUT transactional? 

(http://www.intertwingly.net/wiki/pie/PaceNonEntryResources also calls 
for PUT and DELETE.)

-John Panzer

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 2 Jul 2004 13:56:33 -0400

> this supportable by all Atom-enabled servers?

http://intertwingly.net/wiki/pie/CarrotVsOrange#head-656ecf72eccf403df5368dd110da502137cd7658

> supportable by all Atom-enabled servers?

I have seen no problems in adding headers to responses
on any server platform.

    -joe

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Jul 2004 20:11:07 +0200

John Panzer wrote:
> ...

That's not the way WebDAV sees it. In general, the OPTIONS method isn't 
supposed to take access privileges into account. The Allow: header lists 
the methods for which you're guaranteed to get a 405 (Not Allowed) 
response. However, when you're not privileged to execute a specific 
method, you would usually get a 403 (Forbidden).

WebDAV defines a much more complex Access Control Protocol (RFC3744); 
however I think it would be overkill to requires this for Atom.

> know if anyone has looked at the details for things like PUT and DELETE.)

I would hope so. To rephrase it, it MUST be possible to implement a 
server in such a way as it conforms both to RFC2518 and Atom.

> o Is PUT transactional?

What's the issue here?

> (http://www.intertwingly.net/wiki/pie/PaceNonEntryResources also calls 

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 02 Jul 2004 23:45:30 +0200

On Fri, 02 Jul 2004 10:14:39 -0700, John Panzer <[email-masked]> wrote:

> I like PUT and DELETE too.

Cool. :-)

> I didn't put them into PaceSimpleResourcePosting because I didn't
> think they were necessary and they need some more work to be properly
> defined.

They are properly defined, at least in HTTP. And they're already in use in  
the Atom API[1], so I don't see a problem in using them elsewhere.

> I'm frankly really lazy and want someone else to do the work.

What work? The writeup on the Pace?

> Asbjørn, would you like to volunteer? :^)

When I know what to volunteer for; sure. :-)

> Can all Atom servers support PUT and DELETE on resources?

No. It depends on what control you have of the web server and if you can  
do CGI or similar stuff on it. If you can't, Atom API is probably not for  
you, anyway. The format should be more than enough. There is ongoing work  
to find more deployment-friendly ways to support PUT and DELETE, though,  
one of them being SOAP.

> So my first question is, is this supportable by all Atom-enabled
> servers?

I haven't read any requirements list for what it takes to be an  
Atom-enabled server, but I would say that one of the requirements SHOULD  
be to accept PUT and DELETE.

> natural way to do this and I believe this is compatible with WebDAV.

The correct way should be to use OPTIONS on the resource, but as Apache  
doesn't hand OPTIONS requests to CGI's (research done by Ken MacLeod), a  
fallback solution might be to do HEAD instead, and get a 'Allowed' header  
with the available methods in return.

> supportable by all Atom-enabled servers?

It should be, if the server claims to be Atom-enabled. We need to make a  
requirement-list, it seems. Ordinary servers don't support anything but  
GET and POST out of the box, though. They need tweaking and customization  
to actually do something with other verbs, but it's far from impossible.

> know if anyone has looked at the details for things like PUT and DELETE.)

I think we should, but as I haven't even read the whole WebDAV  
specification, I'm not the right monkey to enforce that. I hope someone  
else will take that responsibility, because it would be rather neat if  
Atom could work flawlessly over WebDAV, whenever that's enabled on the web  
server.

> o Is PUT transactional?

No. All HTTP methods act REST-ish, that is, each request is atomic and  
independant of previous or future requests.

____
[1] <url:  
http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.4.3>

---

From: [email-masked] (John Panzer)
Date: Fri, 02 Jul 2004 22:55:00 -0700

Asbjørn Ulsberg wrote:

> No. It depends on what control you have of the web server and if you 
> can  do CGI or similar stuff on it. If you can't, Atom API is probably 
> not for  you, anyway. The format should be more than enough. There is 
> ongoing work  to find more deployment-friendly ways to support PUT and 
> DELETE, though,  one of them being SOAP.
>
I don't think anyone assumes that you can implement Atom without at 
least the equivalent of CGI scripts. :)

Beyond that, I'm a bit confused.  When I say "on resources", I mean to 
ask the following:  I have a URI like this:  
http://example.org/resources/mycat.jpg.  When I do a GET on this URI, I 
retrieve the image/jpeg data.  When I do a PUT to this URI, I replace 
the image/jpeg data.  When I DELETE the URI, I delete the image/jpeg data.

Can all Atom servers, even ones implemented with CGI scripts, handle this? 

I _think_ so.  Some Atom implementations may need to use URIs like 
http://example.org/cgi-bin/resources?name=mycat.jpg, so that their CGI 
scripts can get control on HEAD, GET, PUT, and DELETE.

This is actually important to the context of both 
PaceSimpleResourcePosting and PaceNonEntryResources, because both assume 
that you can take a single URI and use it for both simple GETs (e.g., 
when using an XHTML img[@src]) and for any subsequent PUTs or DELETEs.  
If that assumption works for even CGI-limited servers, I think 
everything would be fine.  If not, then the two Paces above might have 
some issues.

>> controls, shared blogs, etc.). So you need a way to query as to 
>> whether  you can perform an operation.  The Allowed: and Public: 
>> response headers  
>> (http://www.w3.org/Protocols/HTTP/Object_Headers.html#z6) seem like 
>> the  natural way to do this and I believe this is compatible with 
>> WebDAV.
>
>
> The correct way should be to use OPTIONS on the resource, but as 
> Apache  doesn't hand OPTIONS requests to CGI's (research done by Ken 
> MacLeod), a  fallback solution might be to do HEAD instead, and get a 
> 'Allowed' header  with the available methods in return.

Dumb question:  I assume Apache does hand HEAD requests to CGIs?  :^)

> It should be, if the server claims to be Atom-enabled. We need to make 
> a  requirement-list, it seems. Ordinary servers don't support anything 
> but  GET and POST out of the box, though. They need tweaking and 
> customization  to actually do something with other verbs, but it's far 
> from impossible.
>
It's pretty easy if you have control over the server itself (by which I 
mean the ability to remap URLs to your own code).  It sounds like this 
is supportable even for CGI based services too, assuming that web 
servers will just hand the darn verbs to the scripts.

>> o Do we want to ensure that whatever Atom does in this area is 
>> "upward  compatible" with WebDAV?  (I think this is the consensus, 
>> but I don't  know if anyone has looked at the details for things like 
>> PUT and DELETE.)
>
>
> specification, I'm not the right monkey to enforce that. I hope 
> someone  else will take that responsibility, because it would be 
> rather neat if  Atom could work flawlessly over WebDAV, whenever 
> that's enabled on the web  server.
>
>> o Is PUT transactional?
>
>
> No. All HTTP methods act REST-ish, that is, each request is atomic 
> and  independant of previous or future requests.
>
Sorry, what I meant to ask was whether PUT should be required to be 
atomic: When your PUT fails midway through the 1MB cat video upload, is 
the prior content untouched? 

-John Panzer

---

From: [email-masked] (John Panzer)
Date: Fri, 02 Jul 2004 23:01:10 -0700

> I  at least can't see why it shouldn't.
I answered the general PUT/DELETE question earlier, but I missed 
something.  The question above might really be, why can't a client use 
PUT to tell a server to create a resource at an arbitrary location?

My answer is:  Because an Atom server implemented through CGI scripts 
may not be able to support client-specified arbirary URIs.  That is, CGI 
scripts may not be able to field HTTP requests unless the URIs in the 
HTTP requests include "/cgi-bin/scriptname" or similar; so, they can't 
field PUTs to arbitrary URIs.

But they _can_ support PUT and DELETE if the server gets to specify the 
URI for resources, for example 
http://example.org/cgi-bin/resources.pl?res=mycat.jpg.

-John Panzer
http://journals.aol.com/panzerjohn/abstractioneer

---

From: Julian Reschke <[email-masked]>
Date: Sat, 03 Jul 2004 08:18:49 +0200

> the prior content untouched?

I think RFC2616 is silent about that topic, so it seems to be a 
qualify-of-implementation issue. In real life, some servers that map 
directly to filesystem I/O *will* fail to do this properly.

Julian

---

From: [email-masked] (John Panzer)
Date: Sat, 03 Jul 2004 00:40:50 -0700

Julian Reschke wrote:

>> WebDAV.  For example, Allowed: GET HEAD PUT DELETE means that you, 
>> the user making the HEAD request, can perform a PUT to the resource.  
>> Is this supportable by all Atom-enabled servers?
>
>
> That's not the way WebDAV sees it. In general, the OPTIONS method 
> isn't supposed to take access privileges into account. The Allow: 
> header lists the methods for which you're guaranteed to get a 405 (Not 
> Allowed) response. However, when you're not privileged to execute a 
> specific method, you would usually get a 403 (Forbidden).
>

Totally agreed.  And thanks, I think I was reading the wrong thing about 
Allow:.  (I assume you mean "guaranteed NOT to get a 405" :^) ).

-John

---

From: Ryan Tomayko <[email-masked]>
Date: Sat, 3 Jul 2004 03:53:39 -0400

> http://example.org/cgi-bin/resources.pl?res=mycat.jpg.

I know of no web serving environment that does not support the
PATH_INFO variable (or its equivalent for non-CGI based environments).

From http://hoohoo.ncsa.uiuc.edu/cgi/env.html

  PATH_INFO

  The extra path information, as given by 
  the client. In other words, scripts can be 
  accessed by their virtual pathname, followed 
  by extra information at the end of this path. 
  The extra information is sent as PATH_INFO. 
  This information should be decoded by the 
  server if it comes from a URL before it is 
  passed to the CGI script."

So, the following should be possible on all systems:

http://example.org/cgi-bin/resources.pl/mycat.jpg

Also, I may be wrong about this but I don't believe using query
parameters instead of PATH_INFO will make a URI any less URIy. You can
specify query parameters to a POST or PUT along with a request body
carrying application/atom+xml. Query parameters are not
second-class-citizens.

Giving everything a URI does not necessarily mean giving everything a
URI without query parameters. One publishing system may have
service.edit URIs like:

http://example.com/mycat.jpg

and another may have service.edit URIs like:

http://example.com/resource.pl?resource=mycat.jpg

PUT and DELETE requests to either of these URIs should operate on the
logical "mycat.jpg" resource exactly like a GET would. Just because
the second example uses query parameters doesn't make it any less of a
URI and doesn't make it less useful to methods other than GET. The
first example is "prettier" to look at; that's the only difference I
can establish. Am I missing (possibly a lot of) something here?

Ryan

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 03 Jul 2004 21:06:40 +0200

> least the equivalent of CGI scripts. :)

That depends on what part of Atom you're talking about. The format, and  
the correct serving of it, should be able to be implemented by Bob which  
is an unprivileged user[1]. The API, however, is impossible to implement  
on a standard Apache or IIS web server. What would be fun, though, is if  
the Atom API was possible to support just by installing existing WebDAV  
services for the operating system of your choice.

> I have a URI like this: http://example.org/resources/mycat.jpg.  When
> I do a GET on this URI, I retrieve the image/jpeg data.  When I do a
> PUT to this URI, I replace the image/jpeg data.  When I DELETE the
> URI, I delete the image/jpeg data.

Yes. And as the current Atom API is defined, you would use POST to create  
assign 'mycat.jpg' an URI and initially create it.

> Can all Atom servers, even ones implemented with CGI scripts, handle  

Yes. I'm very confident that can be done, but you need some kind of url  
rewrite procedure to have all the HTTP methods routed to an associated CGI  
(or similar) for a seemingly static URI like the one above.

> Some Atom implementations may need to use URIs like

That shouldn't be necessary if you can use something like .htaccess on  
Apache, or have nice administrators on IIS with ASP.NET. The problem is  
that if people somehow can't do rewrite, they would most likely want to  
serve the resources for GETs as 'http://example.org/resources/mycat.jpg'  
but for all the other verbs  
'http://example.org/cgi-bin/resources?name=mycat.jpg'.

This splits the resource in half, kind of, because it is accessible from  
two different URI's. And not that each URI is equal; no, you can only use  
one for GET and the other for PUT and DELETE (for POST, you'd use a  
totally separate URI anyway).

> when using an XHTML img[@src]) and for any subsequent PUTs or DELETEs.

Yes.

> everything would be fine.  If not, then the two Paces above might have  

As the API offers 'service.edit' URI's, I don't think this is a big  
problem. This URI can be something different for PUT than it is for GET.  
It's not very REST-ish or intuitive, but it works for rewrite-disabled  
people and servers.

> Dumb question:  I assume Apache does hand HEAD requests to CGIs?  :^)

Yes, it does.

> servers will just hand the darn verbs to the scripts.

With rewrite in Apache and on IIS, all HTTP methods are handed off to the  
scripts. On Apache, OPTIONS is however, not handed off. I haven't gotten  
time to test how IIS handles OPTIONS, but as we can't rely on that method  
because of Apache's flaw, anyway, I don't think it matters much how IIS  
handles it.

> the prior content untouched?

Oh. This would be very implementation specific, I think, but Atom could  
probably offer some indications on what should happen. I would assume most  
scripts receiving a file would write it to memory before overwriting the  
original file, thus leaving the original intact until the whole bulk is  
received from the client.

____
[1] <url: http://www.intertwingly.net/wiki/pie/UnprivilegedUsers>

---

From: [email-masked] (John Panzer)
Date: Sat, 03 Jul 2004 12:12:57 -0700

>can establish. Am I missing (possibly a lot of) something here?
I totally agree with you; I was just using the query parameter version 
to make the point that the server needs to be able to control the format 
of the URI.  This is still the case even if you use PATH_INFO.  That is, 
clients cannot necessarily be allowed to say "put my cat picture at 
http://example.com/mypictures/cat.jpg" because a server may not be able 
to map that URI to a CGI script.  The URI in some servers has to start 
with the path /cgi-bin/. I am imagining here a hosted environment in 
which URIs to CGI scripts have to have this form, and where the person 
running an Atom service can't remap URIs, etc.  Does that make sense?

At least, such is my understanding of the situation (and of one hosting 
provider that I actually use). 

John

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 03 Jul 2004 21:51:18 +0200

On Fri, 02 Jul 2004 23:01:10 -0700, John Panzer <[email-masked]> wrote:

> [...] an Atom server implemented through CGI scripts may not be able
> to support client-specified arbirary URIs.

True. That's why we need a mechanism to negotiate supported HTTP methods.  
Do a HEAD on the URI you'd like to PUT, and if you don't get 'Accept: PUT'  
in return, then don't do PUT on it. Of course, if you do, you'd most  
likely get «405 method not allowed» in return. In that case, you would  
have to use POST to some other URL to let the server handle the URI space.

> That is, CGI scripts may not be able to field HTTP requests unless the
> URIs in the HTTP requests include "/cgi-bin/scriptname" or similar; so,
> they can't field PUTs to arbitrary URIs.

Those servers probably exist, yes. It's stupid, because most of these  
servers are probably Apache with .htaccess possibilities where you can do  
rewrite.

> http://example.org/cgi-bin/resources.pl?res=mycat.jpg.

Yes. Atom should probably encourage, but not require, the server to do  
some kind of rewrite. Encouraging rewrite would also help pushing the  
idiom of «Cool URI's don't change»[1] forward, which imho is a Good Thing.

____
[1] <url: http://www.w3.org/Provider/Style/URI.html>

---

From: Ken MacLeod <[email-masked]>
Date: 03 Jul 2004 15:55:52 -0500

Asbjørn Ulsberg <[email-masked]> writes:

> > That is, CGI scripts may not be able to field HTTP requests unless
> > the URIs in the HTTP requests include "/cgi-bin/scriptname" or
> > similar; so, they can't field PUTs to arbitrary URIs.
> 
> Those servers probably exist, yes. It's stupid, because most of
> these servers are probably Apache with .htaccess possibilities where
> you can do rewrite.

There seems to be some confusion here about "any random URL on a host"
and the URL space Atom publishing systems expose -- and it has
*nothing* to do with POST, PUT and DELETE or URL rewriting.

PUT and DELETE work anywhere that POST does.

If you're talking about a random URL on a host and wondering if Atom
allows you to PUT/DELETE there, ask yourself the question, "can I POST
there?"  If not, it's probably not a CGI or a server module, it's a
read-only location served by the web server internally -- so it just
doesn't matter whether it supports PUT, DELETE, *or* POST.

URL rewriting is an orthogonal feature, relevant only from the
perspective of someone who wants to map some URL space on the server
to a CGI or module that supports the Atom protocol.

  -- Ken

---

From: Ken MacLeod <[email-masked]>
Date: 03 Jul 2004 17:11:52 -0500

Asbjørn Ulsberg <[email-masked]> writes:

> Atom-enabled server, but I would say that one of the requirements
> SHOULD be to accept PUT and DELETE.

Atom API today is MUST support POST/GET/PUT/DELETE and SHOULD support
the SOAP fallback that uses only POST/GET.

The support is not for the benefit of servers but for some client
libraries that do not have solid support for PUT/DELETE.

  -- Ken

---

From: Ryan Tomayko <[email-masked]>
Date: Sat, 3 Jul 2004 18:15:23 -0400

Ahh, I see. 

So, you could PUT to the following:

http://example.com/cgi-bin/resource.pl/mypictures/cat.jpg

But having "cgi-bin/resource.pl/" in the URI is annoying and limits
where things can be PUT..

Thanks,
Ryan

----- Original Message -----
From: John Panzer <[email-masked]>
[snip]
I totally agree with you; I was just using the query parameter version
to make the point that the server needs to be able to control the
format of the URI.  This is still the case even if you use PATH_INFO. 
That is, clients cannot necessarily be allowed to say "put my cat
picture at http://example.com/mypictures/cat.jpg" because a server may
not be able to map that URI to a CGI script.  The URI in some servers
has to start with the path /cgi-bin/. I am imagining here a hosted
environment in which URIs to CGI scripts have to have this form, and
where the person running an Atom service can't remap URIs, etc.  Does
that make sense?

John

---

From: Ken MacLeod <[email-masked]>
Date: 03 Jul 2004 17:26:12 -0500

I've added a PUT/DELETE FAQ to the wiki that I hope summarizes all the
discussion in this thread and previous threads.

    http://intertwingly.net/wiki/pie/PutDeleteFaq

  -- Ken

---

From: [email-masked] (John Panzer)
Date: Sat, 03 Jul 2004 16:50:40 -0700

Looks good; one minor nit and a question:

>
>     I have a URL '/image/kitten.jpg', can it support PUT/DELETE?
>
> You can't PUT or DELETE, or POST for that matter, to arbitrary 
> locations on the server. Atom editable resources must be at URL 
> locations where a CGI, server module, or server page can respond to them.
>
Should this read "You can't necessarily PUT or DELETE ... to arbitrary 
locations on the server."? That is, there exist servers which do support 
this and also servers that don't support this (as described further down).

>
>     Can I use the OPTIONS method to an Apache server to see if
>     PUT/DELETE are supported?
>
> Apache does not let a CGI program the OPTIONS method (by default?), so 
> it would require additional configuration privileges to change the 
> list of supported methods returned by OPTIONS.
>
> Apache server modules can respond to OPTIONS methods.
>
> At this time, in Atom, if you are provided an EditURI you take that as 
> an indication that PUT/DELETE are supported on that URI.
>
> "...HTTP/1.1 does not require that OPTIONS responses be truthful." -- 
> Roy Fielding <http://archive.apache.org/gnats/378>
>
 From my reading of the RFCs, clients can also use HEAD (and for that 
matter, GET) and look at the Allow: response header the server returns.  
If no header exists, the default allowed methods are HEAD and GET.   If 
the header does exist, it should give the same information it would have 
given for OPTIONS.  So I'm assuming that clients can use HEAD as a 
workaround; is this a valid assumption?  Am I reading the standards 
correctly?

(OK, one other nit:  If you have a NonEntryResource, I don't think you 
don't have an EditURI for it, as defined in the Atom spec.  So I assume 
that the above applies only to Entry resources.)

-John

---

From: [email-masked] (John Panzer)
Date: Sat, 03 Jul 2004 17:29:35 -0700

Asbjørn Ulsberg wrote:

> That depends on what part of Atom you're talking about. The format, 
> and  the correct serving of it, should be able to be implemented by 
> Bob which  is an unprivileged user[1]. The API, however, is impossible 
> to implement  on a standard Apache or IIS web server.

Why?  (If it's already a nongoal to implement the API using 
non-priviledged scripts, great.  I hadn't heard that.)

> What would be fun, though, is if  the Atom API was possible to support 
> just by installing existing WebDAV  services for the operating system 
> of your choice.
>
> Yes. And as the current Atom API is defined, you would use POST to 
> create  assign 'mycat.jpg' an URI and initially create it.
>
Ah, but the context of this discussion is about non-entry resources.  
Which have a special twist that make them slightly different from 
entries -- see below.  (But yes, I agree regarding the POST mechanism -- 
for example, see PaceSimpleResourcePosting).
...

>> http://example.org/cgi-bin/resources?name=mycat.jpg, so that their 
>> CGI  scripts can get control on HEAD, GET, PUT, and DELETE.
>
>
> That shouldn't be necessary if you can use something like .htaccess 
> on  Apache, or have nice administrators on IIS with ASP.NET. The 
> problem is  that if people somehow can't do rewrite, they would most 
> likely want to  serve the resources for GETs as 
> 'http://example.org/resources/mycat.jpg'  but for all the other verbs  
> This splits the resource in half, kind of, because it is accessible 
> from  two different URI's. And not that each URI is equal; no, you can 
> only use  one for GET and the other for PUT and DELETE (for POST, 
> you'd use a  totally separate URI anyway).

Ah, this is the crux of the matter.  The impetus for this discussion is 
non entry resources (PaceNonEntryResources/PaceSimpleResourcePosting).  
I think that non entry resources in these proposals _require_ that a 
single URI be used for all possible methods after creation (GET, PUT, 
DELETE, say).  Here's why:

One of the main use cases is to be able to post an Atom entry which, as 
its XHTML content, has the following fragment:

<img src="http://example.com/myblog/resources/cat1.jpg" align="right"/>A 
picture of Fluffy!<br/>

Note that nowhere else in the universe is there a reference to 
http://example.com/myblog/resources/cat1.jpg, at least when it's first 
uploaded.  (And for cat pictures, let's face it, do we really want more 
references?)  Well, a client could of course keep track of it locally, 
but let's say it doesn't. 

Suppose I want to update the picture of Fluffy with a better version 
(fixed redeye) a day later.  How do I do this?  Well, first I need to 
retrieve the entry with my Atom client; this gives me the XHTML in a 
WSYWIG editor.  Then I presumably drag and drop the fixed picture on top 
of the old one, and the client notes that I've updated the content.  
Then I save the entry.  My client _may_ be smart enough to do a PUT of 
the new content to http://example.com/myblog/resources/cat1.jpg instead 
of a POST to create yet another picture.  Since it only has the GETtable 
URI for the resource at hand, the simplest thing is for that URI to 
support PUT as well.  If it doesn't, how do we get a URI that _does_ 
support PUT?  Specify yet another introspection API?

The current Atom introspection mechanisms for entries do not work for 
this case.  To start with, you can have any number of non-entry 
resources associated with an entry:

<p><img src="http://example.com/myblog/resources/cat1.jpg" 
align="right"/>A picture of Fluffy!</p>
<p><img src="http://example.com/myblog/resources/cat2.jpg" 
align="right"/>A picture of Buffy!</p>
...

But you only have one service.edit URI associated with an entry. So 
there's a cardinality problem at the very least. :)

This all assumes that we want to be able to create clients that attempt 
to deal with compound documents intelligently (not that Atom should 
require such clients, but I think it should _allow_ them; we certainly 
plan to work on such clients, and we want to use Atom wherever 
possible).  That is, I don't think that users should be forced to manage 
the URIs of their cat pictures manually.  I think that intelligent 
clients can help with the management a lot, given just standard linking 
constructs such as <img src>.

>> PaceSimpleResourcePosting and PaceNonEntryResources, because both 
>> assume  that you can take a single URI and use it for both simple 
>> GETs (e.g.,  when using an XHTML img[@src]) and for any subsequent 
>> PUTs or DELETEs.
>
>
> Yes.
>
>> everything would be fine.  If not, then the two Paces above might 
>> have  some issues.
>
>
> problem. This URI can be something different for PUT than it is for 
> GET.  It's not very REST-ish or intuitive, but it works for 
> rewrite-disabled  people and servers.

Note that we're not talking about entries in this context, we're talking 
about non-entry resources and there is no service.edit URI that points 
at any of them (at least under 
PaceNonEntryResources/PaceSimpleResourcePosting). 

-John

---

From: Ryan Tomayko <[email-masked]>
Date: Sun, 4 Jul 2004 00:55:03 -0400

>     http://intertwingly.net/wiki/pie/PutDeleteFaq

Nice. This should clear up a lot of misundestanding on this topic.

I've added a bit about where the "PUT/DELETE needs WebDAV"
misconception may have come from. Feel free to refactor however you
see fit.

Ryan

---

From: Julian Reschke <[email-masked]>
Date: Sun, 04 Jul 2004 10:44:49 +0200

> workaround; is this a valid assumption?  Am I reading the standards 

Well, only if you do it as workaround, that is: try OPTIONS first then 
do HEAD as a last resort. We can't require all servers to return 
"Allow:" headers upon HEAD just because their support for OPTIONS is 
broken. BTW: note that with a complex server supporting WebDAV ACL and 
DeltaV, computing the set of allowed methods may be quite complex and 
certainly isn't something you want to do for each single HEAD request.

Anyway, the simplest way to discover support for PUT is to do the PUT 
request and to look at the HTTP response code. If it's 405, the PUT 
method is not supported for that resource (and a compliant server *then* 
will send an "Allow:" header with the names of supported methods).

Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 04 Jul 2004 11:04:22 +0200

> broken. BTW: note that with a complex server supporting WebDAV ACL and 

This should have read: "...just because support for OPTIONS in other 
servers is broken...".

Julian

---

From: Ken MacLeod <[email-masked]>
Date: 04 Jul 2004 11:47:07 -0500

> > That shouldn't be necessary if you can use something like
> > .htaccess on Apache, or have nice administrators on IIS with
> > ASP.NET. The problem is that if people somehow can't do rewrite,
> > they would most likely want to serve the resources for GETs as
> > 'http://example.org/resources/mycat.jpg' but for all the other
> > verbs 'http://example.org/cgi-bin/resources?name=mycat.jpg'.
> >
> > This splits the resource in half, kind of, because it is
> > accessible from two different URI's. And not that each URI is
> > equal; no, you can only use one for GET and the other for PUT and
> > DELETE (for POST, you'd use a totally separate URI anyway).
> 
> Ah, this is the crux of the matter.  The impetus for this discussion
> is non entry resources
> (PaceNonEntryResources/PaceSimpleResourcePosting).  I think that non
> entry resources in these proposals _require_ that a single URI be
> used for all possible methods after creation (GET, PUT, DELETE,
> say).  Here's why:

Note: it is perfectly acceptable for a publishing system to publish
static, GET-only, instances of a resource in a different URL location,
possibly even on a different host.  We don't have a name or label for
this kind of URI location, WebDAV calls it an "output resource", so
OutputURI sounds good.

The editable resource at the EditURI would support GET/PUT/DELETE (and
whether it is also a PostURI for posting new sub-resources is a
separate concern).  It's also possible that the EditURI might be
restricted to authenticated users.

Atom does not currently have a method for informing a client what the
OutputURI is for resources in general.  Entries can have a
link/@rel=alternate for the browsable OutputURI.

At this time, the publishing system must document the relationship
between the AtomAPI locations (EditURI) and where the resources are
published (OutputURI) so that the user can edit entries appropriately.

> > As the API offers 'service.edit' URI's, I don't think this is a
> > big problem. This URI can be something different for PUT than it
> > is for GET.  It's not very REST-ish or intuitive, but it works for
> Note that we're not talking about entries in this context, we're
> talking about non-entry resources and there is no service.edit URI
> that points at any of them (at least under
> PaceNonEntryResources/PaceSimpleResourcePosting). -John

Notifying editing clients of non-entry resource locations was a
feature of PaceResource, on the principle that <resource> elements
would be in dynamic and index feeds but not displayed as entries in
newsreader clients.

We have to decide carefully in this support because there's a mature
and straightforward solution for this available in WebDAV, PROPFIND,
for indexing collections of resources.

A trimmed-to-relevant portion of the output from

  curl -X PROPFIND -H "Depth: 1" http://test.webdav.org/dav/atom/

<dav:response xmlns:dav="DAV:">
  <dav:href>/dav/atom/kitty.jpg</dav:href>
  <dav:propstat>
    <dav:prop>
      <dav:resourcetype/>
      <dav:getcontenttype>image/jpeg</dav:getcontenttype>
      <dav:creationdate>2004-07-04T16:30:36Z</dav:creationdate>
      <dav:getcontentlength>43397</dav:getcontentlength>
      <dav:getlastmodified>Sun, 04 Jul 2004 16:30:36 GMT</dav:getlastmodified>
      <dav:getetag>"43d4-a985-f0ac8300"</dav:getetag>
    </dav:prop>
    <dav:status>HTTP/1.1 200 OK</dav:status>
  </dav:propstat>
</dav:response>

  -- Ken

---

From: [email-masked] (John Panzer)
Date: Mon, 05 Jul 2004 14:33:49 -0700

First, let me note that these issues only arise when discussing 
PUT/DELETE with non-entry resources.  (That's why I hesitated to add 
PUT/DELETE into the core proposal earlier.)

>this kind of URI location, WebDAV calls it an "output resource", so
I see what you're saying, but I at first glance I think this introduces 
a lot of complexity that needs to be justified.  Why do we need it? 

o PaceSimpleResourcePosting already supports resource URIs on arbitrary 
hosts.
o PaceSimpleResourcePosting doesn't require support for PUT and DELETE, 
so in that sense the resource URI could be an "OutputURI".
o However, PaceSimpleResourcePosting says that servers SHOULD support 
PUT and DELETE on the resource URI itself; that is, the recommended 
approach for doing editing is to use one URI (e.g., 
http://example.org/res/kitty1.jpg) , not many.  We believe this is 
compatible with straightforward WebDAV as well.

#3 is where PaceSimpleResourcePosting currently differs.  I see two 
issues with using mutiple resource URIs:

(1) Many URIs are more complicated than one URI; are there non-edge 
cases where servers or clients need there to be more than one URI?
(2) There doesn't seem to be a way proposed to discover the non-entry 
resources associated with an entry, under the multi-URI approach.

#2 might be confusing, so let me repeat my earlier use case which 
motiviates the one-URI approach:

> One of the main use cases is to be able to post an Atom entry which, 
> as its XHTML content, has the following fragment:
>
> <img src="http://example.com/myblog/resources/cat1.jpg" 
> align="right"/>A picture of Fluffy!<br/>
>
> uploaded.  (And for cat pictures, let's face it, do we really want 
> more references?)  Well, a client could of course keep track of it 
> locally, but let's say it doesn't.
> WSYWIG editor.  Then I presumably drag and drop the fixed picture on 
> top of the old one, and the client notes that I've updated the 
> content.  Then I save the entry.  My client _may_ be smart enough to 
> do a PUT of the new content to 
> http://example.com/myblog/resources/cat1.jpg instead of a POST to 
> create yet another picture.  Since it only has the GETtable URI for 
> the resource at hand, the simplest thing is for that URI to support 
> PUT as well.  If it doesn't, how do we get a URI that _does_ support 
> PUT?  Specify yet another introspection API? 

Ken, could you document how you would address the problem above in the 
multi-URI approach, so we could compare the two approaches?  That is, 
given that http://example.com/myblog/resources/cat1.jpg is just the 
"OutputURI", how would I find the "EditURI" and update the cat picture?  
Or if there are multiple approaches, perhaps you could list them.

>link/@rel=alternate for the browsable OutputURI.
I'm a little puzzled by this.  See the cat picture use case above.  I 
think we'd both agree that http://example.com/myblog/resources/cat1.jpg 
IS the 'OutputURI'.  Where we appear to differ is in whether 
http://example.com/myblog/resources/cat1.jpg is also the 'EditURI'.  
PaceSimpleResourcePosting calls for OutputURI=EditURI.

>published (OutputURI) so that the user can edit entries appropriately.
Ken, do you envision there being publishing-system-specific ways to 
relate the OutputURI and the EditURI, which clients would need to keep 
track of?  Or are you implying that this is a gap in the Atom spec that 
should be filled?  (My proposal: PaceSimpleResourcePosting calls for 
OutputURI=EditURI :).)

>would be in dynamic and index feeds but not displayed as entries in
PaceResource (http://www.intertwingly.net/wiki/pie/PaceResource) 
proposes adding atom:resource elements to the feed.  It doesn't seem to 
have any way to relate the resources to the entries they are logically 
associated with, which PaceSimpleResourcePosting does.  That is, it 
still doesn't address the issue of how, given a specific atom:entry, I 
find the EditURIs for the resources associated with it?

Having a collection of all resources associated with a blog seems like 
the 20% case to me, while being able to go from an entry to its 
associated resources seems like the 80% case. 

I agree with you, Ken, that it would probably be better to let an 
existing standard -- like WebDAV -- deal with the 20% case where users 
actually _do_ want to manually manage a collection of random resources 

>    <dav:status>HTTP/1.1 200 OK</dav:status>
Yep.  My proposal is, if you want a collection of resources like this, 
use WebDAV and PROPFIND, not Atom.

-John

---

From: [email-masked] (John Panzer)
Date: Mon, 05 Jul 2004 15:59:38 -0700

Julian Reschke wrote:

>
> John Panzer wrote:
>
>>  >From my reading of the RFCs, clients can also use HEAD (and for 
>> that matter, GET) and look at the Allow: response header the server 
>> returns.  If no header exists, the default allowed methods are HEAD 
>> and GET.   If the header does exist, it should give the same 
>> information it would have given for OPTIONS.  So I'm assuming that 
>> clients can use HEAD as a workaround; is this a valid assumption?  Am 
>> I reading the standards correctly?
>
>
> method is not supported for that resource (and a compliant server 
> *then* will send an "Allow:" header with the names of supported methods).
>
Hmm.  What exactly does Apache return for OPTIONS?  Does it return a 200 
success code?  Quick experiment with 1.3.26, virtual host environment:

-------
$ telnet johnpanzer.com 80
Trying 64.71.137.114...
Connected to johnpanzer.com.
Escape character is '^]'.
OPTIONS /cgi-bin/hello.cgi HTTP/1.1
Host: johnpanzer.com

HTTP/1.1 200 OK
Date: Mon, 05 Jul 2004 22:14:54 GMT
Server: Apache/1.3.26 (Unix) AuthMySQL/2.20 PHP/4.1.2 mod_gzip/1.3.19.1a 
mod_ssl/2.8.9 OpenSSL/0.9.6g
Content-Length: 0
Allow: GET, HEAD, POST, OPTIONS, TRACE
-------
So, assuming that if Apache intercepts OPTIONS it will return 200 OK and 
say that it doesn't support PUT and DELETE by default...

...how can I tell whether OPTIONS is broken?  Should a client check for 
PUT and DELETE in OPTIONS, and then if they're not there, do a HEAD and 
see if _that_ lists them?

-------
telnet johnpanzer.com 80
Trying 64.71.137.114...
Connected to walnut.he.net (64.71.137.114).
Escape character is '^]'.
HEAD /cgi-bin/hello.cgi HTTP/1.1
Host: johnpanzer.com

HTTP/1.1 200 OK
Date: Mon, 05 Jul 2004 22:17:59 GMT
Server: Apache/1.3.26 (Unix) AuthMySQL/2.20 PHP/4.1.2 mod_gzip/1.3.19.1a 
mod_ssl/2.8.9 OpenSSL/0.9.6g
Content-Type: text/html
-------
 
The script actually gets called for HEAD, so it could put in something 
like Allow: GET, HEAD, POST, OPTIONS, TRACE, PUT, DELETE.  In this case, 
the script isn't written nicely and doesn't put in Allow: at all. 

Here's my question:  If you have a server where OPTIONS returns a valid 
Allow: header for your script (but disallows PUT and DELETE), _and_ for 
efficiency reasons does not return an Allow: header for HEAD... how do 
you distinguish this from a 'broken' server that looks like the one 
above?  I can't see any way.  So a client is going to have to ignore the 
result of OPTIONS completely and just try the method, as Julian 
suggested.  Which is a shame, because clients can't then be smart about 
what options they present to the user.

Alternatively, we could just say a server SHOULD support OPTIONS/Allow: 
; clients SHOULD trust the results; if OPTIONS says PUT is disallowed, 
clients have a workaround: POST a new copy of the resource (getting a 
new URL) and move the link(s) in question.  Which they should have the 
freedom to do anyway.  (Of course clients can also do an attempt-to-PUT 
first and only create a new resource if it returns a 405.)

Here's what this might look like as an edit to PaceSimpleResourcePosting:

> To support capability discovery, servers SHOULD support the 
> [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2 OPTIONS] 
> method on the resource URI and return the list of other allowed 
> methods in the 
> [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7 
> Allow:] header.  Further, PUT or DELETE MUST each return an 
> appropriate HTTP status if not implemented -- e.g., 405. (Not all CGI 
> based servers can provide a valid Allow: header from OPTIONS. If PUT 
> and DELETE are in Allow:, user agents SHOULD assume they are in fact 
> available for the URI.  If not, user agents MAY assume they are not 
> available.  User agents MAY alternatively attempt PUT or DELETE to the 
> URI and check the result status.)  (Note that a workaround for lack of 
> PUT support is to create a new resource via ResourcePostURI and update 
> the relevant link to point to the new resource.)
>
> Atom servers MAY optionally also support some profile of WebDAV for 
> these resources.  The above capability discovery and usage is upwardly 
> compatible with WebDAV, so clients MAY elect to support either or both.

-John

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Jul 2004 09:30:26 +0200

> see if _that_ lists them?

That's a good question. For plain WebDAV this isn't a problem, because 
it requires the server to *also* return the "DAV:" response header in 
the response (<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_DAV>).

> what options they present to the user.

I think that's correct.

> first and only create a new resource if it returns a 405.)

This probably will work.

Julian

---

From: Janne Jalkanen <[email-masked]>
Date: Wed, 07 Jul 2004 16:52:20 +0300

> directly to filesystem I/O *will* fail to do this properly.

Temp files are standard in upload implementations.  Anyone who writes 
such bad code that a broken upload can break an existing good file 
should be shot.

Just my 2c.

/Janne