Re: [Resteasy-developers] NumberFormatException when bad input path param

[Martin A. <sp...@ma...>]

It was obviously not as easy as that. The question is what happens  
when the arguments are passed as request headers or question  
parameters instead of on the path. 404 in those cases too?

I.e. if you have a method

@Path("{number}")
public AccountResource getAccount( @PathParam("number") int number ) {

and you pass ?number=bad or request.setRequestHeader( "number", "bad )

404 in all cases?

That's what I've checked in now. I've also changed the expected  
behaviour for bad list values (i.e. ?number=bad1&number=bad2) to also  
give 404.

I could see an argument that:

1) Subresource locator with bad path argument => 404
2) Bad path argument => 400
3) Bad header argument => 400
4) Bad request argument => 400

That would require some further refactoring though. Thoughts?

M

On 7 Jul 2008, at 02:19, Ryan J. McDonough wrote:

> Oh, I don't think so. I just realized I had this response queued up  
> in my drafts and just wanted to weigh-in is all. On a related note,  
> I did make the package rename on Thursday night so be sure to take  
> an update. Also, I'm adding slf4j to the project so we have some  
> type of logging framework available. I'll be make those commits and  
> publishing details in the wiki later tonight or Monday morning.
>
> Ryan-
>
> On Jul 6, 2008, at 4:09 PM, Martin Algesten wrote:
>
>>
>> An easy enough fix. With your reasoning I +1 404. I take it Bill is  
>> not disagreeing?
>>
>> I'm planning to get my patches into the source tree Mon-Tue this  
>> week.
>>
>> Cheers,
>> Martin
>>
>> On 6 Jul 2008, at 14:29, Ryan J. McDonough wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Sorry for the slow response, but I had this sitting in my draft  
>>> forlder for w while. But I disagree with 400 here and it should be  
>>> a 404 since an AccountResource identified by a String identifier  
>>> will never exist. Therefore, if you attempt to access a resource  
>>> with a String-based ID, it should return a 404 rather than just a  
>>> 400. Since we can understand the request and know that the  
>>> resource isn't available, we should return the client a more  
>>> specific message.
>>>
>>> Ryan-
>>>
>>>
>>> On Jun 16, 2008, at 3:15 PM, Bill Burke wrote:
>>>
>>>> I'd say 400.  Bad request.  Please log jira bug.  Thanks.
>>>>
>>>> Martin Algesten wrote:
>>>>>
>>>>> In my code I have the following subresource locator:
>>>>>
>>>>> @Path("{number}")
>>>>> public AccountResource getAccount( @PathParam("number") int  
>>>>> number ) {
>>>>>
>>>>> This is the only method that can match anything. If I pass in  
>>>>> something
>>>>> that can not get interpreted as a string I get a 500 and a
>>>>> NumberFormatException - which doesn't seem entirely right.  
>>>>> However from
>>>>> the spec I struggle to work out what it should be. 404? 400?. I  
>>>>> plan to
>>>>> file it as a bug, but would like to provide a test case for it  
>>>>> as well -
>>>>> so I need to work out the wanted behaviour.
>>>>>
>>>>> Here's the stack trace:
>>>>>
>>>>> java.lang.NumberFormatException: For input string: "q"
>>>>> at
>>>>> java 
>>>>> .lang 
>>>>> .NumberFormatException.forInputString(NumberFormatException.java: 
>>>>> 48)
>>>>> at java.lang.Integer.parseInt(Integer.java:447)
>>>>> at java.lang.Integer.valueOf(Integer.java:553)
>>>>> at
>>>>> org 
>>>>> .resteasy 
>>>>> .util 
>>>>> .StringToPrimitive 
>>>>> .stringToPrimitiveBoxType(StringToPrimitive.java:18)
>>>>> at
>>>>> org 
>>>>> .resteasy 
>>>>> .StringParameterInjector 
>>>>> .extractValue(StringParameterInjector.java:143)
>>>>> at org.resteasy.PathParamInjector.inject(PathParamInjector.java: 
>>>>> 44)
>>>>> at
>>>>> org 
>>>>> .resteasy 
>>>>> .MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
>>>>> at  
>>>>> org.resteasy.ResourceLocator.createResource(ResourceLocator.java: 
>>>>> 64)
>>>>>
>>>>> Martin
>>>>>
>>>>>