UWS 0.4

[Guy Rixon]

Hi Paul,

I see UWS sites split into two classes w.r.t security: those that  
control access to the data and those that don't (the majority). The  
secured ones ought to do as you and Pat suggest. For the unsecured  
ones, access is anonymous, so there's no problem with listing the  
jobs or even the job details.

Cheers,
Guy

On 16 Jun 2008, at 12:37, Paul Harrison wrote:

>
> On 2008-06 -13, at 19:38, Patrick Dowler wrote:
>
>>
>> On 2008-6-6 02:22, Paul Harrison wrote:
>>> I have uploaded a new version (0.4) of the UWS document
>>
>> I am in the process if implementing a REST UWS framework (pretty
>> straightforward so far) and have the following comments about the  
>> 0.4 draft:
>>
> I can see that you have been pretty busy ;-)...
>
>> 2.1.1
>>
>> Second sentence says the job list can be read (GET), presumably by  
>> anyone. I
>> don't think that is a good idea as I don't think it should be  
>> required that
>> users can see what others are doing (provider policy issue).
>
> Although the document does not go into the security considerations  
> for the pattern (the next version of the document should have a  
> security section to make these matters explicit). I think that  
> there is an implicit assumption that the general IVOA  
> authentication and authorization standards apply - in this case if  
> a service that considered its content sensitive  was applying the  
> UWS pattern, then it would not be unreasonable for the service to  
> list only the jobs that were "owned" by the caller - as you say  
> that is a provider policy issue. My feeling is that even for a  
> fairly security sensitive service, it would not be unreasonable  
> though to see the list of jobs (as this gives some idea how busy  
> the service is), but not be able to see the job detail for jobs  
> that the caller does not own.
>>
>>
>> 2.1.6
>>
>> The second sentence should be removed now that POST to phase is  
>> the way to do
>> this.
> done for the next draft
>>
>>
>> 2.2.1.3.1
>>
>> The response when creating a job is a 303 (redirect) to the URI  
>> for the job.
>> That works fine, but http also provides a 201 (CREATED) which also  
>> contains a
>> Location header. Maybe cosmetic... maybe browsers don't handle 201  
>> well.
>>
>>
>> 2.2.1.3.2
>>
>> The response is supposed to be a 303 (redirect) to the job list  
>> URI, but given
>> the above (job list may not be readable) perhaps a better response  
>> to DELETE
>> would be 204 (NO CONTENT), which means "yes I did that" and there  
>> is no
>> response entity (and in the case of a user agent, it does not  
>> change document
>> view).
>>
>>
>> 2.2.1.3.5
>>
>> The response to changing the phase is a 303 to the (changed) phase  
>> resource,
>> but http also provides a 202 (ACCEPTED) for the purpose of async  
>> operations.
>> The response entity should contain an indication of the current  
>> status, which
>> could still be the Location of the (changed) phase since the phase  
>> nominally
>> expresses the status. As above, maybe cosmetic... maybe browsers  
>> don't handle
>> 202 well.
>>
>  I had not really considered these more detailed status values, and  
> as you say they do appear to be a more "RESTful" way of doing  
> things. Browsers sort of know the 303 trick and work pretty well  
> with it wrt not repeating POSTs with the back button etc. From what  
> I can tell (just looking at the behaviour of firefox/safari/opera/ 
> ie6) they do not respond as you would hope to the 201 status and  
> location header - they just display a blank page. It was one of the  
> design goals that UWS could be driven in a reasonably intuitive way  
> by common browsers, so I think that we must stick with the 303.
>
> Perhaps we should put in feature requests with the browser vendors  
> to get them to respond as per the spec to these other statuses. I  
> am not sure that Firefox even responds to 303 in the way that is  
> correct, as refreshing the page returned by a redirect causes the  
> original request URI to be resent, which is not what is desired. It  
> does however do what is expected for a 302....
>
>>
>>
>>
>> 2.2.1.3.6
>>
>> "aboted" in the first sentence should be "aborted"
>>
>> For the above http codes I mentioned, I only looked at the text/ 
>> meaning in
>>
>>   http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>>
> corrected in next draft
>
>> --
>> Finally, a suggestion for possible inclusion:
>>
>> In thinking about using the UWS pattern, it occurs to me that most  
>> services
>> will probably allow for the specifying of input data. Should there  
>> be a
>> standard "input" resource (there is a result) with standard  
>> semantics? If a
>> specific service does not support inputs (due to the specific spec  
>> not
>> defining them or making them optional), it could just respond with a
>> 403 (FORBIDDEN) or 405 (METHOD NOT ALLOWED).
>>
>> "input" would be a resource list and could operate like the job  
>> list, where
>> the caller can POST to the input resource to create a new  
>> resource, and gets
>> a 303 to the new resource (to find out it's name). With POST,  
>> there could be
>> a required URI param with the URI (http, vos, etc) to the content.  
>> Maybe
>> PUT should be used for inline content. Presumably the input list  
>> would be
>> mutable until PHASE=RUN and after that they would not be.
>>
>>
>
> as you know from previous private emails on this matter, I am not  
> against including the inputs in the pattern for UWS - I think that  
> Guy has some reservations and would like to see more evidence of   
> the general applicability of such a facility before including it in  
> the pattern.
>
> Cheers,
> 	Paul.
>
>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3006 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/grid/attachments/20080616/8deb01df/attachment-0001.bin>