custom HTTP headers

[Andy Fish]

Dear esteemed gurus of HTTP (I hope you're out here somewhere)

please excuse the crosspost but there isn't really an HTTP newsgroup as
such.

I have a GUI app which will communicate with a server over HTTP. I would
like to return more status information than just the straight HTTP error
code, but I want to leave the response body as HTML or XML so that a browser
client can make sense of the output as well. I don't want the GUI app to
have to parse a browser-friendly HTML page to get the extra status
information.

my question is, is it acceptable to add my own custom HTTP header to convey
this information? am I guaranteed that proxy servers will pass on any such
unrecognised headers unmodified?

Many thanks

Andy

 

[Chris Morris]

my question is, is it acceptable to add my own custom HTTP header to convey
this information? am I guaranteed that proxy servers will pass on any such
unrecognised headers unmodified?

Well, it's not guaranteed, the proxy server could be buggy, but they
should pass-through unrecognised headers. Starting it X- is probably
worth doing so you don't end up with something that's then added with
a different meaning in HTTP/1.2

 

[Andy Fish]

thanks, I'll give that a try then. good advice to start it with "X-"

I was trying to use the reason code text to convey that information but I
found that sometimes seems to get munged in transport (especially for 200
OK)

 

[Ben_]

I think it definitely allowed to define custom HTTP headers.

Here is what I think relevant in RFC2616:
"
6.2 Response Header Fields
Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as
entity-header fields.
<...>
7 Entity
Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers.
<...>
7.1 Entity Header Fields
Entity-header fields define metainformation about the entity-body or,
if no body is present, about the resource identified by the request.
Some of this metainformation is OPTIONAL; some might be REQUIRED by
portions of this specification.
<...>
The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and MUST be forwarded by
transparent proxies.
"

If I understand correctly, if an HTTP response header is not one of those
defined in the RFC, it's an entity. Since entity headers are extensible, you
can define new headers and proxies on the path must forward them
transparently.

So, as long as it works, I'd use a custom header and would only hack
something if I'd encountered problem with non HTTP compliant proxies.

I've seen it done, but I don't know about the habit of using 'X-' as a
prefix. Anyway, I'd indeed do it, to avoid collisions in the future (but -
if you like making things complicated - you could theoratically have
collisions with someone else in the X-namespace as well .

Ben.

 

[Malcolm Hoar]

I have a GUI app which will communicate with a server over HTTP. I would
like to return more status information than just the straight HTTP error
code, but I want to leave the response body as HTML or XML so that a browser
client can make sense of the output as well. I don't want the GUI app to
have to parse a browser-friendly HTML page to get the extra status
information.

my question is, is it acceptable to add my own custom HTTP header to convey
this information? am I guaranteed that proxy servers will pass on any such
unrecognised headers unmodified?

Personally, I'd be inclined to place the status information in the
document body -- within a META or even a comment tag. This could be
done in such a manner that you can quickly extract the info without
the overhead of complete SGML parsing. Several practical advantages:

1. You're not going to hit unexpected problems with proxies.

2. The status information *can* easily be viewed for diagnostic
purposes.

3. Such a mechanism would still work with certain types of dynamic
page or servlet where errors can arise (or information become
available) *after* the response headers have already been sent.
I have seen many cases where this consideration forces the issue.

--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| (e-mail address removed) Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~