RE: Re: Handler.defaultHandle() 501 vs 405?

[Jerome Louvel]

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
   
 
 
 

Re: Handler.defaultHandle() 501 vs 405?

[Thierry Boileau]

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. 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.

Regards,
Thierry Boileau

On 12/9/06, John D. Mitchell [EMAIL PROTECTED] wrote:


The Handler.defaultHandle() method returns a 501
(Status.SERVER_ERROR_NOT_IMPLEMENTED).

However, RFC2616 says:

10.5.2 501 Not Implemented

   The server does not support the functionality required to fulfill the
   request. This is the appropriate response when the server does not
   recognize the request method and is not capable of supporting it for
   any resource.


Note the last phrase about no about to support that [method] for any
resource.

Doesn't that imply that the defaultHandle() method should return a 405
(Status.CLIENT_ERROR_METHOD_NOT_ALLOWED) instead?

Thanks,
John