Mailing List Archive: content type params

content type params

May 2, 1995, 3:30 PM

Post #1 of 9 (1756 views)

At some point, "clean_content_type()" was added to Apache..

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
void clean_content_type ()
{
/* How marvelous. Arena doesn't *accept* "text/html; level=3"
* as a MIME type, so we have to strip off the parms.
*/

char *cp = strchr(content_type, ';');

if (cp) {
while (cp > content_type && isspace (cp[-1]))
--cp;
*cp = '\0';
}
}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

I just gave Arena 0.96 some params and it was perfectly happy.
Time to yank this routine out of Apache, or is it still needed ?

robh

Re: content type params [ In reply to ]

May 2, 1995, 3:33 PM

Post #2 of 9 (1746 views)

> The only reason for this to have been present was as a sop to Arena.
> If current Arenas work, yeah, yank it.

I'll add a patch in a few mins.

It'll get my +1.

Time for 0.6.3 me thinks.

rob

Re: content type params [ In reply to ]

May 2, 1995, 3:39 PM

Post #3 of 9 (1748 views)

> > The only reason for this to have been present was as a sop to Arena.
> > If current Arenas work, yeah, yank it.
>

On the subject of yanking unwanted code, we can now remove the
compile option for old style dates.... Netscape is 1.1 is fixed.
I'll patch that too.

robh

Re: content type params [ In reply to ]

May 2, 1995, 5:32 PM

Post #4 of 9 (1754 views)

The only reason for this to have been present was as a sop to Arena.
If current Arenas work, yeah, yank it.

rst

Re: content type params [ In reply to ]

May 3, 1995, 10:22 AM

Post #5 of 9 (1747 views)

>At some point, "clean_content_type()" was added to Apache..
In patch E24.

Re: content type params [ In reply to ]

May 3, 1995, 10:44 AM

Post #6 of 9 (1755 views)

Date: Wed, 3 May 95 11:27 BST
From: drtr@ast.cam.ac.uk (David Robinson)

So my question is, could set_content_type_and_parms() be removed as well?
Or is the NULL default content type important somewhere?
Rst?

It's important --- the MultiViews stuff specifically does *not* want
find_ct to default the content_type to DefaultType (or it would treat
any file whose MIME type couldn't be otherwise identified, including
Emacs backups and files with nonsense extensions like .xgif as
text/plain --- remember that bug?)

rst

Re: content type params [ In reply to ]

May 3, 1995, 11:21 AM

Post #7 of 9 (1749 views)

>we can now remove the compile option for old style dates....
+1 on E89.

Re: content type params [ In reply to ]

May 3, 1995, 11:27 AM

Post #8 of 9 (1747 views)

> > The only reason for this to have been present was as a sop to Arena.
> > If current Arenas work, yeah, yank it.

> I'll add a patch in a few mins.

Re patch E88.
The orignal patch, E24, not only introduced clean_content_type() (for removing
parameters from a c.t.) and changed probe_content_type and set_content_type()
to call it; it also added set_content_type_and_parms(). This routine
was like the original set_content_type(), and does not call clean_content_type.

So after your patch, http_mime.c contains:
void set_content_type(char *file) {
find_ct(file,1,default_type);
}

void set_content_type_and_parms(char *file) {
find_ct(file,1,"");
}

So my question is, could set_content_type_and_parms() be removed as well?
Or is the NULL default content type important somewhere?
Rst?

David.

Re: content type params [ In reply to ]

May 3, 1995, 3:53 PM

Post #9 of 9 (1758 views)

> So my question is, could set_content_type_and_parms() be removed as well?
> Or is the NULL default content type important somewhere?
> Rst?

>It's important --- the MultiViews stuff specifically does *not* want
>find_ct to default the content_type to DefaultType...

Ok, so it's just the name (set_content_type_and_parms) that's misleading.
+1 on Rob's patch, anyway.

David.