Why return HTTP 500 when parameters are missing from a function call?

[Rupert Rawnsley]

If a client request to a CFC component is missing a parameter, you get the following sort of exception:

;The parameter parameter name to function function name is required but was not passed in.;lucee.runtime.exp.ExpressionException: The parameter deviceid to function checkInV2 is required but was not passed in.
at lucee.runtime.type.UDFImpl.defineArguments(UDFImpl.java:172)
at lucee.runtime.type.UDFImpl._call(UDFImpl.java:335)
at lucee.runtime.type.UDFImpl.callWithNamedValues(UDFImpl.java:210)
at lucee.runtime.ComponentImpl._call(ComponentImpl.java:698)
at lucee.runtime.ComponentImpl._call(ComponentImpl.java:588)
at lucee.runtime.ComponentImpl.callWithNamedValues(ComponentImpl.java:1928)
...

However, the HTTP status code returned is 500, which indicates a server error. Wouldn't it be more appropriate to return a 4XX response of some sort? Can this behaviour be overridden at least?

This matters to me because my AWS load balancer gets twitchy when it sees too many 5XX errors and may kill off perfectly healthy server instances in the cluster.

[Denard Springle]

I believe this replicates the behavior of ACF. That said, however, you can get Lucee to always return a 200 status code:

Within the Lucee Admin go to Settings -> Error and untick the 'Status Code' checkbox and click update.

That will prevent your AWS load balancer from killing off your instances.

HTH

-- Denny

[Jean Moniatte]

404 are for missing resources (URLs). The missing parameter in your cfc call is a server side error (nothing the client can do about), so the 500 status code is correct. Do not force Lucee to always return 200, it breaks standards everything around your application rely on. Instead, fix your cfc call or the cfc itself if the parameter is not required.

Thanks

Jean

--
Get 10% off of the regular price for this years CFCamp in Munich, Germany (Oct. 20th & 21st) with the Lucee discount code Lucee@cfcamp. 189€ instead of 210€. Visit https://ti.to/cfcamp/cfcamp-2016/discount/Lucee@cfcamp
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/66508cd7-8f85-4ee7-968e-db3f8d254eca%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Rupert Rawnsley]

I would agree that malformed internal function calls are my fault and hence best represented by HTTP 500, but the calls I'm worried about are direct requests from clients (web browsers and apps). These are out of my control in many cases.

Indeed, HTTP 404 would be wrong, but HTTP 400 matches the scenario doesn't it? 

On Wednesday, 28 September 2016 17:08:29 UTC+1, jmoniatte wrote:

404 are for missing resources (URLs). The missing parameter in your cfc call is a server side error (nothing the client can do about), so the 500 status code is correct. Do not force Lucee to always return 200, it breaks standards everything around your application rely on. Instead, fix your cfc call or the cfc itself if the parameter is not required.

Thanks

Jean

On Wed, Sep 28, 2016 at 7:01 AM, Denard Springle <denard....@gmail.com> wrote:

I believe this replicates the behavior of ACF. That said, however, you can get Lucee to always return a 200 status code:

Within the Lucee Admin go to Settings -> Error and untick the 'Status Code' checkbox and click update.

That will prevent your AWS load balancer from killing off your instances.

HTH

-- Denny

--
Get 10% off of the regular price for this years CFCamp in Munich, Germany (Oct. 20th & 21st) with the Lucee discount code Lucee@cfcamp. 189€ instead of 210€. Visit https://ti.to/cfcamp/cfcamp-2016/discount/Lucee@cfcamp
---
You received this message because you are subscribed to the Google Groups "Lucee" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

[Jean Moniatte]

I did not realize your clients where requesting the cfc directly. So maybe put the extra logic in the cfc itself and throw a 400 when required parameters are missing.

To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ac20fa7f-8efb-49f0-b0e3-cf1be2e889bf%40googlegroups.com.

[Rupert Rawnsley]

Unfortunately it never reaches my code. The Lucee engine throws the error, which limits my options.

[Julian Halliwell]

Could you make the argument to your CFC method optional instead of
required to stop Lucee throwing the exception? Then you can test for
its existence within your function and abort with a 400 response if
its not defined or of the correct type.

On 28 September 2016 at 18:17, Rupert Rawnsley

[Rupert Rawnsley]

That's an interesting suggestion, sort of like an assertion. I will ponder on that.

[Julian Halliwell]

I'd think of it more as "defensive" programming. If your cfc method is
being exposed remotely then you shouldn't rely on or trust any
parameters being passed.

Required arguments are only really appropriate when the method caller
is another part of your system which is able to handle exceptions.

On 28 September 2016 at 22:47, Rupert Rawnsley

<rupert....@gmail.com> wrote:
> That's an interesting suggestion, sort of like an assertion. I will ponder on that.

On 28 September 2016 at 20:07, Julian Halliwell

[Rupert Rawnsley]

It works for the missing parameters case, but I get a large number of requests where the method name is missing or corrupt and there's nothing I can do about those.

I've found I can modify the return code in the error.cfm pages:

<cfheader statuscode="400" statustext="Bad Request"/>
We're sorry - An Error Occurred

I'll post again if I come up with anything more comprehensive.

[Julian Halliwell]

Fair enough. I'm surprised I can't seem to find a built-in way of dealing with this. OnMissingMethod() doesn't seem to work when the component is called directly.

But the following should handle both missing and invalid method names (POST or GET):

component{

if( IsNull( method ) OR !methodExists( method ) ){
 header statuscode=400;
 abort;
}

private boolean function methodExists( required string methodName ){
 var myMethods=GetMetaData( this ).functions;
 for( var thisMethod in myMethods ){
  if( thisMethod.name IS methodName )
   return true;
 }
 return false;
}

remote function test() returnformat="plain" {
 return "test";
}

}

Julian.