UWS 0.4

[Paul Harrison]

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.

>
>