-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Int Route Constraint Still Matching for Long #1565
Comments
@PureKrome - cc'd you in |
At what point does it error out?
But we aren't dictating the size of the int when used in routing, so we're using the maximum value available in .NET which is Get["/details/{value:int}"] = _ =>
{
long value = (long)_.value;
return value;
} This is perfectly value. |
It errors when i try and pass the dynamic param to my method, e.g: Fair enough, so the doco here is a bit misleading.. I assumed I only want int32 values, so i guess i'll have to use: bit messy... |
Maybe the other @NancyFx/most-valued-minions can take a look, see if they think this is something that should be changed i.e:
Or if doco needs to be updated. |
If you specify int as a route constraint and the number is larger it should fail IMO with a helpful error message |
so @jchannon you're saying that and not |
@PureKrome - we would name them their .NET alias's int / long / short |
Yeah, I wondered why that was when I first saw it, but didn't change it. It uses I guess we should ask @mat-mcloughlin why? I suggest we introduce |
We can still use |
😉 |
Correct @jchannon but we should add all 4 primitive number types. byte/short/int/long that all map to the implementation in .NET. |
ITS ASSIGNED TO ME! |
Passing the buck on this one. After discussions it was decided that there wasn't much need for both int and long so under advisement just had the int constraint parsed with long. You want me change? |
I can change it, I don't mind. But yeah I remember you put int, and i decided to make it long and just leave it at that, I didn't think people would want to constrain to actual length of the int types. |
Yeah me neither ;) and stop stealing the easy PR's trying to get more involved ;) |
If you want to do it, go head :) I was just taking responsibility because it was me who said go with long. |
Tbh I still don't see a business need to distinguish |
Make it value:number then parse it as long then that should encompass all |
Breaking change right there |
Yup On Friday, 13 June 2014, mat-mcloughlin [email protected] wrote:
|
Lol busted
|
I agree with you @jchannon |
I'm not suggesting we do uint/ulong. Just the 4 signed types. |
😄 Yes I know I was just exaggerating I thought of adding |
Eeeh, @jchannon how would that fix anything? The problem is that when you parse something as
|
So what types we going with? |
Something that will fit @jchannon's mum. |
@khellang realised that after i said it. we either have one |
Maybe we just do How often do people ever use |
agree |
ok, I'll add in long |
Resolved by #1569 |
I have a route like this:
Get["/details/{value:int}"]
But if i pass a value like this:
/details/1111111111111111111
It still matches, and errors with the following message:
Value was either too large or too small for an Int32
Which is valid. BUT, it shouldn't have matched in the first place, according to the documentation here
The text was updated successfully, but these errors were encountered: