the only hiccup we have is that we require HTTP/1.0 with no keepalives for it to work
Graham Leggett wrote:
Peter Van Biesen wrote:
I've run into a webserver ( www.bea.com ) that does not send the Content-Type headerline back. Default behaviour of the proxy code is to add "Content-Type: text/plain; charset=ISO-8859-1". However, this will render the page in plaintext in stead of html.
This behaviour is in the Apache core, not the proxy code.
I've read the rfc but I'm not entirely sure, as I understand it, if you send content back, Content-Type and Content-Encoding are mandatory, no ? Anyway, if not, I'd vote to not add the text/plain line and just send the page on to the browser without a Content-Type field.
According to RFC2616, in the event of a missing content type, the application can either try intelligently guess the content type by looking at the content, or it should fall back to application/octet-stream.
Apache however specifies a directive DefaultType for what the default content-type should be should one not be specified, and this directive defaults to text/plain, which in theory violates the RFC. Changing this to text/html will work around the problem.
BTW: The RFC you should be looking at is RFC2616, not RFC2068, which is obsolete.
Regards, Graham
