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.
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
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
JeanOn Wed, Sep 28, 2016 at 7:01 AM, Denard Springle <@Denard_Springle> 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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/66508cd7-8f85-4ee7-968e-db3f8d254eca%40googlegroups.com
https://groups.google.com/d/msgid/lucee/66508cd7-8f85-4ee7-968e-db3f8d254eca%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
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> wrote:
Unfortunately it never reaches my code. The Lucee engine throws the error, which limits my options.
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.On Wed, Sep 28, 2016 at 9:15 AM, Rupert Rawnsley <@Rupert_Rawnsley> wrote:
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
https://tools.ietf.org/html/rfc7231#section-6.5.1 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-20
16/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.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/lucee/66508cd7-8f85-4ee7-968e-db3f8d254eca%40googlegroups.com
https://groups.google.com/d/msgid/lucee/66508cd7-8f85-4ee7-968e-db3f8d254eca%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
–
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 lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/ac20fa7f-8efb-49f0-b0e3-cf1be2e889bf%40googlegroups.com
https://groups.google.com/d/msgid/lucee/ac20fa7f-8efb-49f0-b0e3-cf1be2e889bf%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
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
https://tools.ietf.org/html/rfc7231#section-6.5.1 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 <javascript:>> 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 CFCamp 2016
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 <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/66508cd7-8f85-4ee7-968e-db3f8d254eca%40googlegroups.com
https://groups.google.com/d/msgid/lucee/66508cd7-8f85-4ee7-968e-db3f8d254eca%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
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.On 29 September 2016 at 11:48, Rupert Rawnsley <@Rupert_Rawnsley> wrote:
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.
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:
We're sorry - An Error Occurred
I’ll post again if I come up with anything more comprehensive.On Thursday, 29 September 2016 11:23:13 UTC+1, Julian Halliwell wrote:
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 <javascript:>> 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 <julianh...@gmail.com <javascript:>> wrote:
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.
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_Rawnsley> 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 <@Julian_Halliwell> wrote:
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.