Hi again, Excellent points John and Thierry! Here are the changes that I've made: * removed the "defaultHandle()" to force explicit setting of the status in context * Handler is now abstract and findTarget() must be implemented * findTarget() is now automatically invoked by the general handle() method * if findTarget returns "null": 404 Not Found * if no method is specified in the request: 400 Bad Request * if no matching handle* method could be found: 405 Method Not Allowed * if allow* method returns false: 405 Method Not Allowed * the set of allowedMethods is automatically updated introspecting allow* methods
Best regards, Jerome > -----Message d'origine----- > De : Thierry Boileau [mailto:[EMAIL PROTECTED] > Envoyé : dimanche 10 décembre 2006 11:22 > À : discuss@restlet.tigris.org > Objet : Re: Re: Handler.defaultHandle() 501 vs 405? > > I think that you make good remarks! > > >If the target is null then is that a sign of of a bug in the > implementation or a broken request? > Answering this question helps taking the right way. I don't > know really what a null target means. > > best regards, > Thierry > > > > On 12/10/06, John D. Mitchell <[EMAIL PROTECTED]> wrote: > > On 12/9/06, Thierry Boileau <[EMAIL PROTECTED] > wrote: > > John, > > > > At this time in the Handler class, the 501 status is > used for 2 cases : > > - the method of the request is unknown (not a GET, > PUT, etc), > > - the method is known, but there is no handler for > the resource. > > > > I think we all agree that 501 status fits the first case. > > If the target is null then is that a sign of of a bug in the > implementation or a broken request? > > For the former, it's arguable that a 501 makes sense > but, IMHO, a > straight 500 is more correct. I.e. the 501 implies > that we haven't > implemented something and that's a known condition > whereas the 500 > indicates server bug. > > In the latter case, it seems pretty clear to me that > the response > should be a 400 (Bad Request) since it's actually a > malformed request. > Though, that evolves to the 405 since we know its the > method name > that's the problem and so we can use the 405 directly. > > > But, for the > > second case, I would like to ask the following > question : if the response > > status is 405, is it possible to define the allowed > methods for the resource > > though the resource cannot be handled? > > I wonder if status 404 should be used instead in this case. > > I think that would be very misleading. > > In terms of returning something useful in the allows > header, isn't the > work basically the same as what's already being done for the > Handler.handle() method? I.e ., lookup what handle*() > methods are > defined. > > Thanks, > John > > > >
