httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: Fix :(
Date Sun, 08 Oct 2000 17:35:59 GMT
Ok...

  I'm dead on certain that David identifies the entire problem here.
I have no problems loading pages from the browser or NC, only from
telnet, where (as he points out) you are getting single character
buckets.  I don't know if this should hold up the release, but Ryan,
since you are most intimately familiar, you should make the call...

  Alot of users will try telnet'ing to test the browser, so a big
red warning in the announce is the minimum requirement to roll the
Alpha as is.  If you have a patch, and would like to test it, my PC
will be happy to page me when your note comes back.  I'd rather roll
today, since my next group of changes should not be in 2.0a7.  

  I'm even holding off the 1.3.13 <Directory /> forward and brand-new 
canonical name stuff, since it's complete rework for 2.0 and too 
complex for comfort.  Win32 is serving, and I'd like to keep it that 
way for at least one Alpha release :-)

  Finally, you need win32 .mak files with the tarball... once you tag
the tree, I will generate them from the tagged checkout.  Before you
roll the tarball I'll email them (straight to you), and once you check
in the tarball I'll compare notes and roll a dos line-endings .zip.

  Your call

Bill

> -----Original Message-----
> From: David Reid [mailto:dreid@jetnet.co.uk]
> Sent: Sunday, October 08, 2000 1:00 PM
> To: New HTTPD mailing list
> Subject: Fix :(
> 
> 
> Sorry, the fix doesn't cure the problem for me.
> 
> I'll try to show what I'm seeing which will hopefully make it more 
> obvious (party last night so I may not be totally lucid :))  I've 
> trimmed out the comments from the code.  I'll let those who've been 
> hacking about with it find a fix as they know the code better than I.
> 
>     while (1) {
>         while (e->length == 0) {
>             AP_BUCKET_REMOVE(e);
>             e->destroy(e);
> 
>             ap_get_brigade(c->input_filters, b);
>             if (!AP_BRIGADE_EMPTY(b)) {
>                 e = AP_BRIGADE_FIRST(b); 
>             }
>             else {
>                 return -1;
>             }
>         }
>         retval = e->read(e, &temp, &length, 0);
>         /* retval == 0 on SUCCESS */
> 
> >>> retval = 0
> >>>	length = 1
> >>>	*temp = 'G'
> 
>         if (retval != 0) {
>             total = ((length < 0) && (total == 0)) ? -1 : total;
>             break;
>         }
> 
> >>> this doesn't apply...
> 
>         if ((toss = ap_strchr_c(temp, ASCII_LF)) != NULL) { 
>             length = toss - temp + 1;
>             e->split(e, length + (temp[length] == '\0' ? 1 : 0));
>             apr_cpystrn(pos, temp, length + 1);
> 	    
>             AP_BUCKET_REMOVE(e);
>             e->destroy(e);
>         }
>         c->input_data = b;
>         e = AP_BRIGADE_FIRST(b); 
> 
>         n -= length;            /* Keep track of how much of 
> s is full   
> */
>         pos += (length - 1);    /* and where s ends           
>            
> */
>         total += length;        /* and how long s has become  
>            
> */
> 
> >>> n = 8191
> >>> *pos = '\0'
> >>> total = 1
> >>>
> >>> So this next check will fail as we only have a single 
> character and 
> not a line!
> 
>         if (*pos == '\n') {     /* Did we get a full line of 
> input?      
> */
>             while (pos > (s + 1) && (*(pos - 1) == ' '
> 				     || *(pos - 1) == '\t')) {
>                 --pos;          /* trim extra trailing spaces 
> or tabs    
> */
>                 --total;        /* but not one at the 
> beginning of line  
> */
>                 ++n;
>             }
>             *pos = '\0';
>             --total;
>             ++n;
>             break;
>         }
>         else {
> 	    break;       /* if not, input line exceeded buffer size */
> >>> Break here and that's all folks!
> 	}
>     }
> 
> The problem is that the telnet app sends each character as 
> soon as it's 
> typed, and doesn't wait for the CR.  This could be a problem 
> that only 
> BeOS will exist but other poorly written apps may well do the same?
> 
> Of course the other problem is that in this case what is passed on 
> results in the error being sent inifinitely to the client in 
> a loop that 
> needs the server to be killed to exit :(  Not good.  
> 
> david
> 
> 
> 

Mime
View raw message