<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">When you're actually getting a representation of a resource with HTTP-GET, it's possible to defeat the caching using HTTP headers in the responses. (I admit to being hazy about the details; I've never had to set this up explicitly.) This is part of HTTP and there is quite a lot about it in RFC2616:<div><br></div><div><span class="Apple-style-span" style="font-family: 'Lucida Grande'; font-size: 11px; white-space: pre-wrap; -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; "><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13">http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13</a>
</span><br><div>My experience is that it Just Works if you use GET only for its proper purpose.</div><div><br></div><div>You might also manage cache transparency if you were misusing HTTP-GET to change or create a web resource. However, note section 13.4 of the RFC which seems to suggest subtle behaviour by some user agents. Even if it seems to work it's still against the rules.</div><div><br></div><div>Guy</div><div><div><br></div><div><br><div><div>On 2 Nov 2009, at 16:56, Tom McGlynn wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Guy Rixon wrote:<br><blockquote type="cite">Tom,<br></blockquote><blockquote type="cite">if you want to get the job list then go ahead and do HTTP-GET. That's part of UWS (although implementations may restrict the set of you reported to be those owned by the caller). What you can't do is use HTTP-GET to submit a query via UWS. If you want to use GET to do a query then you're doing a synchronous query by definition.<br></blockquote><blockquote type="cite">Cheers,<br></blockquote><blockquote type="cite">Guy<br></blockquote><br>But I recall from earlier in this discussion some clever fellow said...<br><br><blockquote type="cite">GET responses can be cached, and the caching is out of your control as a service provider - it may be on the user's LAN (HTTP proxy) or in their client (browser cache). If you send the same query twice then via GET, <br></blockquote>> for the second request you could get the response for the first, pulled from the cache,<br><blockquote type="cite">and no new job.<br></blockquote><br>If what you said earlier is correct, then I can't rely on what I get back from a GET call. I might be getting a cached response and not the current state of the system. If caching is truly an issue, then there doesn't seem to be any reliable way to get the job list.<br><br>Tom<br><br><blockquote type="cite">On 2 Nov 2009, at 14:13, Tom McGlynn wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Paul Harrison wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Guy has already done a good job of answering most of these points - I<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The UWS design of the two stage process is for two principal reasons<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a) to be able to manipulate job metadata parameters before the job is<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">run - e.g. the DestructionTime - and receive the feedback from the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">service whether it is prepared to honour such requests before actually<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">committing the job.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">b) to allow complete parameter namespace freedom on the job creation<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">step - i.e. if PHASE is used by UWS then it could not be a parameter<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">for the implementation protocol.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">So if for a particular implementation using UWS there is no problem<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">with meeting that second condition, then there is no particular reason<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">why job metadata parameters could not be included with the initial UWS<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">job creation step if desired - this would require revision of the UWS<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">specification to include this possibility - I think that this is a<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">small enough change to be added into the document as part of the RFC -<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">it does have a larger impact on possible service implementers however<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- their code might not be structured to allow this change easily. For<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a generalized UWS client the change would not be so great, all that<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">would happen is that after the initial submission a job object would<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">be returned with the PHASE=EXECUTING, and general clients should not<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">make any assumptions about state in their coding, so should probably<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">still be able to react appropriately.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Just as a side note to show that UWS is not so strange in this<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">multiple interaction between client and server - consider what happens<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">when a web browser loads a web page - it does the initial get of the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">html, then parses this html and then gets images, javascript etc.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">before the page is shown to the user.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I trust the goal is not to require that UWS services need to have the complexity of an interactive visual Web browser. The protocol should cater to simple applications as well.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I'd be perfectly happy with a change that made it clear that the request that created the job could return it in any state. In fact, even without the desire to be able to start jobs at creation, that is probably needed to accommodate the situation where there is a problem detected in creating the job but we want the user to be able to parse the error with IVOA protocol level error handling.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The specific text that I find problematic is in 2.1.3:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> PENDING: the job is accepted by the service but not yet committed for execution by the client. In this state the job quote can be read and evaluated. This is the state into which a job enters when it is first created.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">in conjunction with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">2.2.3.1 Creating a job.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Posting a request to the job list creates a new job (unless the service rejects the request).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I would suggest something like the following changes<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In 2.1.3 add somewhere<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> Phases are ordered with PENDING before QUEUED, QUEUED before EXECUTING and EXECUTING before the trio of COMPLETED, ABORTED and ERROR. The state of a job may change only to a later state but need not pass through any intermediate state. A job may be created in any state.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Delete the last sentence in the definition of PENDING.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I think it would be desirable to suggest how a job could be created in the run state even if this is not required by the standard It would be possible to do this without polluting the parameter name space by specifying a new URI for that. E.g., ${jobs} creates a new request but does not start it. ${jobs}/run could create and start the job if that is permitted in the given service. However I find the worry about pollution of the parameter name space less than compelling, since we require certain parameters to be used in calls to start the job running or to alter other aspects of the job. It would be poor practice to have phase= mean one thing in a job creation request and mean something else in a job update request. In effect, these parameters are reserved already.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This discussion brought up another thing that's not really clear. 2.2.3.1 has the little parenthetical phrase "(unless the service rejects the request)" which is neither explained, nor is the action implied in rejection specified. I think something like:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> Errors may occur in the creation of the job. Where possible a job should be created in the ERROR phase with a error message that describes the problems. If this is not possible, an HTTP 500 error must be returned.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">would be clearer for implementation and should replace that phrase.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Finally, one new issue/concern. [This probably reflects a lack of understanding on my part but if so then perhaps it could be clarified in the standard.]: It doesn't seem like there is any valid way to get the current job list.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I can't do a GET request for /{$jobs} because that's cacheable and the list is dynamic. And I can't do a POST request for it since a post to /{$jobs} means that I'm creating a new job and I'm supposed to be redirected to the job information for the newly created job.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">So how do I get to it?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In my TAP implementation I assume that any request to create a new job needs to have a REQUEST= parameter and if I don't see this I return the job list. If I do, I create the new job. However this doesn't seem to be literally correct. I suppose you could say that I'm 'rejecting' the request and since that behavior is undefined I can do anything I want. Relying on undefined behavior doesn't seem satisfactory.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>Tom<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></div></blockquote></div><br></div></div></div></body></html>