Validation and HTTP Headers

[NotionCommotion]

I've seen some client applications which use the server to respond with an HTTP header other than 200 to indicate that a request did not pass validation.

 

It appears that a 400 header is the correct one to return.  It appears that if the browser made a request, it did not pass validation and thus received a 400 header, it would not attempt to perform the request again without some modification.  Is this correct?  Is the request cached by the browser?

 

6.5.1.  400 Bad Request

 

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

 

 

 

Reference: https://tools.ietf.org/html/rfc7231#section-6.5.1

 

10.4.1 400 Bad Request

 

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

 

 

Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1

 

 

I then considered that validation is not always permanent.  For instance:

 

1. User submits a date after today, and the request doesn't meet validation today but will so in the future.
2. User submits multiple identical requests which must have some minimum time span between them, and fails the validation preventing them from making the same request in the future.
3. Business rules are relax so that the previous request which didn't pass validation now does.
4. User submits a record which must be unique, attempts to submit the same record which now fails because it is not unique, deletes the record, and then attempts to re-submit the record which should no longer fail the unique constraint.
5. Probably a lot more...

 

Are my concerns valid?  If so, are there other headers which should be used other than 400 which will allow the client to repeat the request?  Also, will the client receiving a 400 status cause tracking solutions such as qbaka, trackjs, etc to log the error as a JavaScript error?

 

I look forward to hearing any real world experience or sound hypothetical advice regarding this.

 

Thank you

[ginerjm]

Wouldn't it be better to handle these conditions within your app with a more user-friendly response so they can fix and resubmit without dealing with the browser?

[joel24]

**edit - I'm assuming you're talking about using a 400 header for an ajax response in validating a form post?

 

Yes I think it's great to use an erroneous http header to separate the success and failure functions within the ajax query and then display the error message to the user whilst maintaining clean code.. 

 

i.e. sending a 422 ( or other ) http header response... this way you can handle your ajax as such/

 $.ajax({
   url: "test.html",
   global: false,
   success: function() {
       //handle the 200 success
   },
   error: function() {
        //catch the 422 or other and show the message to the user
   }
 });

Edited April 22, 2015 by joel24

[ginerjm]

An erroneous http header is great?

 

I dunno what you're doing down there, but have fun at whatever it is. I know that if I was using a website and it spit out headers for various diff codes instead of just telling me in plain English what I did wrong, I wouldn't frequent that site anymore.

[NotionCommotion]

An erroneous http header is great?

 

I dunno what you're doing down there, but have fun at whatever it is. I know that if I was using a website and it spit out headers for various diff codes instead of just telling me in plain English what I did wrong, I wouldn't frequent that site anymore.

 

The user wouldn't see the header unless they had Firebug or a console open.  The client would get the header, and would provide a user friendly response.

[NotionCommotion]

 

**edit - I'm assuming you're talking about using a 400 header for an ajax response in validating a form post?

 

Yes I think it's great to use an erroneous http header to separate the success and failure functions within the ajax query and then display the error message to the user whilst maintaining clean code.. 

 

i.e. sending a 422 ( or other ) http header response... this way you can handle your ajax as such/

 $.ajax({
   url: "test.html",
   global: false,
   success: function() {
       //handle the 200 success
   },
   error: function() {
        //catch the 422 or other and show the message to the user
   }
 });

 

 

Exactly.  Just looked into 422.  Do you know if it tells the client to not try the identical request again?  Was my concern about a 400 code doing this correct?

[joel24]

422 is the most applicable, twitter API also uses this when a request does not pass validation... 

 

** Edit - removing my query asking confirmation of what you're trying to achieve, then I reread your above statement regarding firebug and confirmed you're doing an ajax request **

 

 

 

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions.

Edited April 22, 2015 by joel24

[ginerjm]

So now that it turns out to be a response from/to an ajax request, my point remains the same.

 

Notion - you began this topic with the concern about using the "correct" header for a response. Again - why use something that today you can't even name for returning an inter-application reply? Just send back an error message that your caller will understand and react appropriately to. Why all the drama? Why should your two pieces of code have to use headers to convey a message? Seems like overkill to me.

[NotionCommotion]

So now that it turns out to be a response from/to an ajax request, my point remains the same.

 

Notion - you began this topic with the concern about using the "correct" header for a response. Again - why use something that today you can't even name for returning an inter-application reply? Just send back an error message that your caller will understand and react appropriately to. Why all the drama? Why should your two pieces of code have to use headers to convey a message? Seems like overkill to me.

 

Yes, an ajax request.  Should have said so.

 

Some jQuery plugins (x-editable for instance) have an error callback and are built to display a error message when receiving any response other than 200.  This allows the server to do the following:

http_response_code(400);
echo('Your input must be between 40 and 80 degrees');

If desired, one could set up the error callback to display a general service unavailable message if code 500 is received.

 

 

Alternatively, I am sure I could have the server return something like:

echo(json_encode(array('status'=>0, 'error'=>'Your input must be between 40 and 80 degrees')));

and then use the plugins success callback to present the error.

 

 

Just trying to better understand the implications of both approaches.

[joel24]

I would send the json string with the error message and the 422 header so you can inform the user and separate the logic... otherwise you'll end up with the if/else conditions cluttering the success method.

 

Here's a simplified example though you can play with it - this is a very opinionated topic, end of the day it's the method which will render the cleanest most reusable code for your application.

function jsonResponse($httpCode,$message)
{
    http_response_code($httpCode);
    return(json_encode(array('message'=>$message')));
}

 $.ajax({
   url: "test.html",
   global: false,
   success: function() {
       //handle the 200 success
   },
   error: function() {
        //catch the 422 and display the message
   }
 });

Edited April 22, 2015 by joel24

[ginerjm]

Yes, an ajax request.  Should have said so.

 

Some jQuery plugins (x-editable for instance) have an error callback and are built to display a error message when receiving any response other than 200.  This allows the server to do the following:

http_response_code(400);
echo('Your input must be between 40 and 80 degrees');

If desired, one could set up the error callback to display a general service unavailable message if code 500 is received.

 

 

Alternatively, I am sure I could have the server return something like:

echo(json_encode(array('status'=>0, 'error'=>'Your input must be between 40 and 80 degrees')));

and then use the plugins success callback to present the error.

 

 

Just trying to better understand the implications of both approaches.

[ginerjm]

Alternatively, I am sure I could have the server return something like:

 

echo(json_encode(array('status'=>0, 'error'=>'Your input must be between 40 and 80 degrees')));and then use the plugins success callback to present the error.

Again - Why Why Why?

 

What is wrong with your ajax-called script returning a simple error message to the caller? Or is there something else you are not telling us, like this is destined to be a universal target for other apps to use and the error message has to be more generic instead of specific?

[NotionCommotion]

Again - Why Why Why?

 

What is wrong with your ajax-called script returning a simple error message to the caller? Or is there something else you are not telling us, like this is destined to be a universal target for other apps to use and the error message has to be more generic instead of specific?

 

No, nothing I'm not telling you  No universal target.  Just a reply to a normal ajax request.  Still the server needs to inform the client that the server is not fond of the request.

[ginerjm]

A simple returned message can do this for you. Why not let the called script return the exact message you want to pass to the user instead of making the caller deduce some msg from whatever you are proposing to do? Let's face it - if the rejection is based upon a logical error or programming error then you need to re-write something. OTOH if it's simply a matter of a business logic error or user-input error, shout it to the user!