0

I'm trying to set a custom HTTP 1.0 status code in order to return more descriptive error messages via AJAX (using jQuery).

In PHP I have something like:

header( 'HTTP/1.0 909 Hello World' );
exit;

This works as expected on my development environment using Apache 2.2.15 but it does not work on the production webserver running LiteSpeed 5.5. LiteSpeed instead returns a 200 OK.

Using this:

header( 'HTTP/1.0 404 Hello World' );
exit;

Apache returns the 404 with the text above. LiteSpeed replaces the custom text with the default 'Not Found'.

Any idea how to override this feature in LiteSpeed to make it work the same way as Apache? I understand they are supposed to be comparable webservers.

Any ideas, please do let me know.

-P.

paperclip
  • 2,280
  • 6
  • 28
  • 39

1 Answers1

0

First, why HTTP 1.0 and not 1.1?

Second, you're trying to do things that aren't defined in the HTTP spec. LiteSpeed probably checks the headers its being asked to send and replaces values it doesn't recognise with some default value.

You shouldn't be trying to force HTTP to behave in a non-standard way, as soon as you do, it ceases to be HTTP. The specifications are there to make sure that software implemented at different times by different people can interoperate, and how it should behave if you don't follow the spec is completely undefined.

Apache letting a header it doesn't know through is perfectly acceptable behaviour, and so is LiteSpeed's behaviour of refusing to let it through. Making demons fly out of your nose would also be a valid thing for the server to do in this case. And what is the client meant to do with an HTTP response code it doesn't recognise?

If you need to send additional information in the header, why not add a new header? The following should do.

header ('X-My-App-Header: Hello World!');
GordonM
  • 31,179
  • 15
  • 87
  • 129
  • All valid points and maybe I should adopt 'X-Custom-Error: Hello World' instead for better cross-platform compatibility. In response to what does the user do with it, well I then interpret/handle the response to deliver a more descriptive error message so thats not really the issue. Nevertheless I take the point that this may not be best practice so would welcome better alternatives to achieve the above. – paperclip Apr 20 '12 at 11:54
  • 1
    Well like I suggested, you can just attach custom headers (a header with a name beginning with X-) to convey any information beyond what the HTTP specification allows you to return. HTTP does have a pretty rich set of predefined status codes as well though, so I'd suggest returning a valid HTTP status code from the ones available that best fits the situation, along with an X-header with more information. – GordonM Apr 20 '12 at 12:00