Alex Rivera | Logout

Proper use of HTTP status codes in a "validation" server

Asked 2008-12-12T12:31:57.850
23

Among the data my application sends to a third-party SOA server are complex XMLs. The server owner does provide the XML schemas (.xsd) and, since the server rejects invalid XMLs with a meaningless message, I need to validate them locally before sending.

I could use a stand-alone XML schema validator but they are slow, mainly because of the time required to parse the schema files. So I wrote my own schema validator (in Java, if that matters) in the form of an HTTP Server which caches the already parsed schemas.

The problem is: many things can go wrong in the course of the validation process. Other than unexpected exceptions and successful validation:

  • the server may not find the schema file specified
  • the file specified may not be a valid schema file
  • the XML is invalid against the schema file

Since it's an HTTP Server I'd like to provide the client with meaningful status codes. Should the server answer with a 400 error (Bad request) for all the above cases? Or they have nothing to do with HTTP and it should answer 200 with a message in the body? Any other suggestion?

Update: the main application is written in Ruby, which doesn't have a good xml schema validation library, so a separate validation server is not over-engineering.

xml http validation xsd http-status-codes
Edit
Report

3 Answers

18

It's a perfectly valid thinking to map error situations in the validation process to meaningful HTTP status codes.

I suppose you send the XML file to your validation server as a POST content using the URI to determine a specific schema for validation.

So here are some suggestions for error mappings:

  • 200: XML content is valid
  • 400: XML content was not well-formed, header were inconsistent, request did not match RFC 2616 syntax
  • 401: schema was not found in cache and server needs credentials to use for authentication against the 3rd party SOA backend in order to obtain the schema file
  • 404: Schema file not found
  • 409: the XML content was invalid against the specified schema
  • 412: Specified file was not a valid XMl schema
  • 500: any unexpected exception in your validation server (NullPointerExceptions et al.)
  • 502: the schema was not found in cache and the attempt to request it from the 3rd party SOA server failed.
  • 503: validation server is restarting
  • 504: see 502 with reason=timeout
answered 2008-12-15T14:13:00.980
2

I'd go with 400 Bad request and a more specific message in the body (possibly with a secondary error code in a header, like X-Parse-Error: 10451 for easier processing)

answered 2008-12-12T12:36:15.640
-1

That sounds like a neat idea, but the HTTP status codes don't really provide an "operation failed" case. I would return HTTP 200 with an X-Validation-Result: true/false header, using the body for any text or "reason" as necessary. Save the HTTP 4xx for HTTP-level errors, not application-level errors.

It's kind of a shame and a double-standard, though. Many applications use HTTP authentication, and they're able to return HTTP 401 Not Authorized or 403 Forbidden from the application level. It would be convenient and sensible to have some sort of blanket HTTP 4xx Request Rejected that you could use.

answered 2008-12-12T13:32:12.393

Your Answer