[Zope3-dev] DISCUSS: Correct sequence for PUT

[Jim Fulton]

Paul Everitt wrote:
> 
> On Thursday, Feb 20, 2003, at 00:05 Europe/Paris, Jim Fulton wrote:
> 
>> Paul Everitt wrote:
>>
>> ...
>>
>>> 2) I'm not sure Zope 3 is doing the PUT correctly.  I did a PUT of a 
>>> new resource, and RFC 2616 (HTTP/1.1) Section 9.6 says that a status 
>>> code of 201 should be returned.  Also, the server should return a 
>>> Location: header with the URI of the newly created resource.
>>> Perhaps I'm reading 9.6 incorrectly?
>>
>>
>> Maybe, but I probably just missed these points. This should be easy 
>> enough to fix.
> 
> 
> Thanks.  Note that it isn't currently a problem for me.
> 
>> Would you mind submitting a collector entry.
> 
> 
> Done.

Thanks.

...

> For the purposes I need in Moztop, either way will work, procedural or 
> known-schema.
> 
> Do you have another suggestion for how to do this?

I think it's fine to use HTTP "methods" where the semantics match.
Otherwise, I think it's better to use an RPC mechanism, like SOAP,
which isn't implemented yet, or XML-RPC.


>>> To make this hard, presume two constraints:
>>
>>
>> ...
>>
>>> 1) HEAD to see if it exists.
>>> 2) PUT to create it, sending as the request body some XML for 
>>> construction.  (I could do a PUT and then a PROPPATCH, but after the 
>>> PUT it is alread constructed, so I defeat the constructor.)
>>> 3) HEAD, just in case the server thinks the URI is different. :^)
>>> 4) PUT to actually send the body.
>>
>>
>> This should be possible. You'd define a named IFileFactory adapter
>> with the suffix as the view name. This factory could parse the body to 
>> get
>> the initial parameters and create the object. The object would then
>> have a IWriteFile adapter to handle putting thye body.
> 
> 
> Ok, makes sense.
> 
> How could we distinguish from the existing PUT case that you have now, 
> and the PUT case I am proposing?  (I have some suggestions, but I'm 
> already in over my head, no pun intended.)

Well, one mechanism is via file extensions. That's the easiest.
Otherwise, you'd have to override the IFileFactory adapter for the extension
you are using to add content sniffing l;ogic.

> Do you know of any realistic (e.g. we've seen them before) cases where 
> the URI returned should be different than the URI submitted?

No. I haven't exactly looked either. Does the spec give any scenarios to
justify this?  Does the spec allow the URI to be different?  We do have
containers that generate their own IDs, so I suppose this would be useful
of clients had a clue.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org