RFC2068 question : is Content-Type mandatory ?

Hello,

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.

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.

Could anybody confirm this for me ?

Thank you !

Peter.

Re: RFC2068 question : is Content-Type mandatory ?

OK, found a complete version of the RFC ( please don't swamp me with
RTFM's :-)) ).

Bottomline: if no Content-Type is present, the content-type should be
application/octet-stream.

I'll post a patch later.

Peter.

Peter Van Biesen wrote:
>
> Hello,
>
> 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.
>
> 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.
>
> Could anybody confirm this for me ?
>
> Thank you !
>
> Peter.

Re: RFC2068 question : is Content-Type mandatory ?

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
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."

Re: RFC2068 question : is Content-Type mandatory ?

FWIW we are successfully reverse proxying BEA weblogic servers (5.1)
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