httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: cvs commit: apache-2.0/src/main http_core.c
Date Fri, 08 Sep 2000 11:47:47 GMT
Jun Kuriyama wrote:
> At 8 Sep 2000 00:35:31 GMT,
> Jim Jagielski <> wrote:
> > I'm wondering if the bug is simply because we're running into
> > a situation when Apache shouldn't be adding a default, and the
> > bug reporter thought it should have. For example, if there is
> > already a charset parameter, then we don't do a thing. If
> > not, we only handle things if the cntent type is "text/plain" or
> > "text/html"...
> I think these selection is done at make_content_type() in
> http_protocol.c.  This function make "content-type" as you specify
> (add "charset" if these is no "charset", and type is "text/plain" or
> "text/html").
> A patch committed is fixing content in "add_default_charset_name", not
> when it is using.  Old behavior is using "ISO-8859-1" for text/html or
> text/plain though you specify another string to "AddDefaultCharset".

Yes, I know the intent of the patch, but does it actually _do_ it?
Again, the old behavior was to update/merge add_default_charset_name
no matter what (as long as not NULL). The new behavior changes
it to be updated/merged only if add_default_charset is Off or On.
But add_default_charset_name is only used if add_default_charset
is On, so the patch should make no difference at all...

Stepping through, the patch says don't merge if add_default_charset is
UNSET. But if add_default_charset is UNSET, add_default_charset_name
isn't used at all, so it shouldn't matter what it is.

That's why I'm confused on how and why and if the patch actually
fixes the bug, or whether there was a bug.

   Jim Jagielski   [|]   [|]
                "Are you suggesting coconuts migrate??"

View raw message