paul.harrison at manchester.ac.uk
Mon Jun 16 04:37:50 PDT 2008
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 ;-)...
> 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.
> The second sentence should be removed now that POST to phase is the
> way to do
done for the next draft
> 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
> 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
> response entity (and in the case of a user agent, it does not change
> The response to changing the phase is a 303 to the (changed) phase
> but http also provides a 202 (ACCEPTED) for the purpose of async
> The response entity should contain an indication of the current
> status, which
> could still be the Location of the (changed) phase since the phase
> 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....
> "aboted" in the first sentence should be "aborted"
> For the above http codes I mentioned, I only looked at the text/
> meaning in
corrected in next draft
> Finally, a suggestion for possible inclusion:
> In thinking about using the UWS pattern, it occurs to me that most
> 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.
> 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
More information about the grid