From patrick.dowler at nrc-cnrc.gc.ca Wed Sep 14 13:06:32 2011 From: patrick.dowler at nrc-cnrc.gc.ca (Patrick Dowler) Date: Wed, 14 Sep 2011 13:06:32 -0700 Subject: faults in deleteNode Message-ID: <201109141306.32586.patrick.dowler@nrc-cnrc.gc.ca> If a client tries to delete a node and one of the parent containers along the path does not exist, section 5.2.4.3 says it should respond with a fault: 500 ContainerNotFound Is there any reason this is not a "404 ContainerNotFound"? The delete method can also respond with a "404 NodeNotFound" if the target node itself does not exist, but that should be fine (in general there are multiple errors that semantically map to the same error code and the fault name in the body helps the client figure out what happened). Along the same lines, it seems the required "500 LinkFound" would be better served with a "400 LinkFound" (bad request). More generally, the main issue I am trying to resolve is that our ops staff monitor http logs for 5xx errors in order to detect server-side failures. I don't think it is correct or intended to have normal "user-inspired" errors use 5xx error codes. Depending on how we resolve this one, I will provide a list of other cases which I think should be 4xx instead of 5xx... or I can make the list first so we know the full impact. PS-editorial: the "404 NodeNotFound" fault is listed twice in the bullet list in this section (3rd and last). -- Patrick Dowler Tel/T?l: (250) 363-0044 Canadian Astronomy Data Centre National Research Council Canada 5071 West Saanich Road Victoria, BC V9E 2M7 Centre canadien de donnees astronomiques Conseil national de recherches Canada 5071, chemin West Saanich Victoria (C.-B.) V9E 2M7 From m.b.taylor at bristol.ac.uk Thu Sep 15 01:43:28 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Thu, 15 Sep 2011 09:43:28 +0100 (BST) Subject: faults in deleteNode In-Reply-To: <201109141306.32586.patrick.dowler@nrc-cnrc.gc.ca> References: <201109141306.32586.patrick.dowler@nrc-cnrc.gc.ca> Message-ID: I'm not much involved with VOSpace, but I agree with Pat that 5xx codes do not sound appropriate here. On Wed, 14 Sep 2011, Patrick Dowler wrote: > If a client tries to delete a node and one of the parent containers along the > path does not exist, section 5.2.4.3 says it should respond with a fault: > > 500 ContainerNotFound > > Is there any reason this is not a "404 ContainerNotFound"? The delete method > can also respond with a "404 NodeNotFound" if the target node itself does not > exist, but that should be fine (in general there are multiple errors that > semantically map to the same error code and the fault name in the body helps > the client figure out what happened). > > Along the same lines, it seems the required "500 LinkFound" would be better > served with a "400 LinkFound" (bad request). > > More generally, the main issue I am trying to resolve is that our ops staff > monitor http logs for 5xx errors in order to detect server-side failures. I > don't think it is correct or intended to have normal "user-inspired" errors > use 5xx error codes. Depending on how we resolve this one, I will provide a > list of other cases which I think should be 4xx instead of 5xx... or I can > make the list first so we know the full impact. > > PS-editorial: the "404 NodeNotFound" fault is listed twice in the bullet list > in this section (3rd and last). > > -- > > Patrick Dowler > Tel/T?l: (250) 363-0044 > Canadian Astronomy Data Centre > National Research Council Canada > 5071 West Saanich Road > Victoria, BC V9E 2M7 > > Centre canadien de donnees astronomiques > Conseil national de recherches Canada > 5071, chemin West Saanich > Victoria (C.-B.) V9E 2M7 > -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From patrick.dowler at nrc-cnrc.gc.ca Tue Sep 20 13:18:34 2011 From: patrick.dowler at nrc-cnrc.gc.ca (Patrick Dowler) Date: Tue, 20 Sep 2011 13:18:34 -0700 Subject: copy/move/pushFrom/pullTo Message-ID: <201109201318.35028.patrick.dowler@nrc-cnrc.gc.ca> We are implementing the various transfers (beyond the client-initiated pushToVoSpace and pullFromVoSpace which we already have) and it isn't entirely clear to me. I'll just refer to copy below since the only difference is the value of keepBytes, but the ideas apply to move as well. First to clarify the server-server copy (eg 5.4.4 pushFromVoSpace). Say we want to copy a file from server A to server B. We are going to get server A to do it, so it is pushFrom and the target gives the source vos URI in server A (to which the transfer is submitted). The transfer also includes protocol(s) with endpoint(s) to which the data is to be written. Is it assumed/required that the client gets those protocol/endpoint(s) itself? eg. they could be some arbitrary http server and the example makes sense, or the destination could be a vospace, in which case the client negotiates a "pushToVOspace" with server B, extracts the protocol/endpoint(s) and then submits them in the transfer job to server A. Then server A does the http PUT (for example) to server B. Can the client simply specify the destination as a (vos) URI? eg let the server negotiate the protocols? If not, is there some scenario that justifies forcing the client to do this? (note: the client would have to get the list of protocols from serverB, construct the transfer with all of them, then send that to serverA and hope there was overlap... so clients would likely get the lists from both and check for overlap and then submit the transfer, which could in theory still fail to find a common usable protocol... so they still have to look in the transferDetails to see what was agreed upon) On the other hand, by requiring a vopsace service to handle external vos URIs, you require them all to be clients too. Sort of a peer-to-peer style... that is an implementation burden, but not a large one since the client part should be common code written to the spec, not implementation-specific. Practically, one more or less implements a client in test code anyway :-) While thinking about that, look at the the internal copyNode: one submits a transfer with a target (the vos URI of the source node) and a direction (the vos URI of the destination node). The two vos URIs are in the same service (same authority). Clearly one wants to express this with just URIs so the service can optimise this operation (and move). If the two vos URIs had different authorities, the source and destination would be in different vospace services... presumably illegal in the current spec (InvalidURI fault?). Thoughts? -- Patrick Dowler Tel/T?l: (250) 363-0044 Canadian Astronomy Data Centre National Research Council Canada 5071 West Saanich Road Victoria, BC V9E 2M7 Centre canadien de donnees astronomiques Conseil national de recherches Canada 5071, chemin West Saanich Victoria (C.-B.) V9E 2M7