Mailing List Archive

0.6.2 must go
Can we please have some discussion/comments on replacing 0.6.2.

The public release looks like skipping straight to 0.6.4.
.3 is stable enough, so lets vote on the for_apache_0.6.3 patches
(all 3 of them ! :-) and get rid of .2 ASAP.

Make .4 public this weekend ?

--
Rob Hartill
http://nqcd.lanl.gov/~hartill/
Re: 0.6.2 must go [ In reply to ]
> Can someone explain the point of B95? What problem is it trying to solve?
>
> It deletes leading spaces in front of a 'header'. But output from a CGI
> script is supposed to conform to the general HTTP spec. Thus
> either such output is illegal, and so removing the spaces is not consistent
> with other apache behaviour (of faulting the script) or
> a line beginning with whitespace is a continuation line, and should be
> passed unmolested.

It squeezes spaces such as

Content-type: text/html

to

Content-type: text/html


Someone pointed out that a script he was using barfed with the
multiple spaces.


robh
Re: 0.6.2 must go [ In reply to ]
> In fact, according to the current HTTP spec, the first form is not allowed!
> (I think that is an oversight.)

> So this is a reasonable adjustment for httpd to make.
> HOWEVER, if you look further to where 'l' is being used in the routine that
> you modified, you will see that your patch breaks any header which the script
> returns that is not parsed by httpd.

Just for the record, this patch was given to us on the bug-report list.

I will look into replacing it though.
Re: 0.6.2 must go [ In reply to ]
> I suggest that instead of playing around with pointers, you either rewrite
> the header (with memmove or similar), _or_ split up the header into
> name/value once and for all, and get rid of the hack of inserting and removing
> '\0' from the header string.
>
> David.


The bug only appears when a script supplies a Content-type of its
own. This happened because of a change from using "scanf" to read
the content-type - presumably to allow parameters in patch B19.

Therefore, we only need to fix the section which saves the content-type
so that it doesn't save a leading space.

Any objection to the following patch...


*** http_mime.c.orig Thu May 4 14:40:09 1995
--- http_mime.c Thu May 11 11:54:40 1995
***************
*** 338,343 ****
--- 338,344 ----
char *endp = l + strlen(l) - 1;
while (endp > l && isspace(*endp)) *endp-- = '\0';

+ while (*l == ' ') l++;
strcpy (content_type, l);
}
else if(!strcasecmp(w,"Location"))





--
Rob Hartill
http://nqcd.lanl.gov/~hartill/
Re: 0.6.2 must go [ In reply to ]
Can someone explain the point of B95? What problem is it trying to solve?

It deletes leading spaces in front of a 'header'. But output from a CGI
script is supposed to conform to the general HTTP spec. Thus
either such output is illegal, and so removing the spaces is not consistent
with other apache behaviour (of faulting the script) or
a line beginning with whitespace is a continuation line, and should be
passed unmolested.

David.
Re: 0.6.2 must go [ In reply to ]
>It squeezes spaces such as
>
>Content-type: text/html
>
>to
>
>Content-type: text/html
>
>
>Someone pointed out that a script he was using barfed with the
>multiple spaces.

In fact, according to the current HTTP spec, the first form is not allowed!
(I think that is an oversight.)

So this is a reasonable adjustment for httpd to make.
HOWEVER, if you look further to where 'l' is being used in the routine that
you modified, you will see that your patch breaks any header which the script
returns that is not parsed by httpd.
i.e. with your patch, a script that returns a header of
J-random-header: value
to httpd causes httpd to send a header of
J-random-header
to the client.

I suggest that instead of playing around with pointers, you either rewrite
the header (with memmove or similar), _or_ split up the header into
name/value once and for all, and get rid of the hack of inserting and removing
'\0' from the header string.

David.
Re: 0.6.2 must go [ In reply to ]
> In fact, according to the current HTTP spec, the first form is not allowed!
> (I think that is an oversight.)

Oh, sure it is -- there is just a conflict between two sections because
I forgot to include literals as "words". I'll get to it just as soon as
I get through my mail (any year now...).

......Roy