headers
Sander Striker | 12 Mar 2002 18:19
Picon
Favicon

RE: [BUG] Limit test 10 is failing

> From: Doug MacEachern [mailto:dougm <at> covalent.net]
> Sent: 12 March 2002 17:36

> On Tue, 12 Mar 2002, Sander Striker wrote:
> 
> > #User-Agent: libwww-perl/5.53
> 
> could be a bug in the client.  try 5.64
> you can also grab:
> http://httpd.apache.org/~dougm/httpd-test-bundle-0.02.tar.gz
> 
> unpack and run:
> % echo | perl Makefile.PL && make install
> 
> (the 'echo |' trick makes all prompts use the default)
> ignore warnings about prerequisites, they are probably complaining missing 
> modules which are about to be installed.

That fixes the problem, but I still find it weird that the
response code can in this case be:
500 (Internal Server Error) short write

Where the correct response code is logged.

Sander
Permalink | Reply | 0 comments |
headers
Aaron Bannert | 12 Mar 2002 19:48

Content-length returned from HEAD requests?

Is it valid for Content-length to be returned from these types
of requests? daedalus is showing it, and I'm seeing it in current CVS.

-aaron
Permalink | Reply | 5 comments |
headers
Aaron Bannert | 12 Mar 2002 19:53

Re: Content-length returned from HEAD requests?

On Tue, Mar 12, 2002 at 10:48:08AM -0800, Aaron Bannert wrote:
> Is it valid for Content-length to be returned from these types
> of requests? daedalus is showing it, and I'm seeing it in current CVS.

Same thing for Content-type for that matter...

-a
Permalink | Reply | 0 comments |
headers
Brian Pane | 12 Mar 2002 19:57
Picon
Favicon

Re: Content-length returned from HEAD requests?

Aaron Bannert wrote:

>Is it valid for Content-length to be returned from these types
>of requests? daedalus is showing it, and I'm seeing it in current CVS.
>
>-aaron
>

I don't think so, unless it's "Content-Length: 0", due to this
part of section 10.2.7 in RFC 2616:
"If a Content-Length header field is present in the response,
its value MUST match the actual number of OCTETs transmitted in
the message-body."

--Brian
Permalink | Reply | 3 comments |
headers
Marc Slemko | 12 Mar 2002 19:58

Re: Content-length returned from HEAD requests?

On Tue, 12 Mar 2002, Aaron Bannert wrote:

> Is it valid for Content-length to be returned from these types
> of requests? daedalus is showing it, and I'm seeing it in current CVS.

of course it is, that's the whole idea of a HEAD... to get the headers
that you would get if you did a GET.
Permalink | Reply | 0 comments |
headers
Ryan Bloom | 12 Mar 2002 19:35

RE: Content-length returned from HEAD requests?

It is a requirement from the spec.  HEAD requests should behave exactly
as GET requests do, except there is no body.

Ryan

----------------------------------------------
Ryan Bloom                  rbb <at> covalent.net
645 Howard St.              rbb <at> apache.org
San Francisco, CA 

> -----Original Message-----
> From: Aaron Bannert [mailto:aaron <at> clove.org]
> Sent: Tuesday, March 12, 2002 10:48 AM
> To: dev <at> httpd.apache.org
> Subject: Content-length returned from HEAD requests?
> 
> Is it valid for Content-length to be returned from these types
> of requests? daedalus is showing it, and I'm seeing it in current CVS.
> 
> -aaron
Permalink | Reply | 0 comments |
headers
Dale Ghent | 12 Mar 2002 20:05

Re: Content-length returned from HEAD requests?

On Tue, 12 Mar 2002, Aaron Bannert wrote:

| Is it valid for Content-length to be returned from these types
| of requests? daedalus is showing it, and I'm seeing it in current CVS.

IIRC, HEAD is analogous to GET, just minus the content itself... so you
should see the full header information as if it were a GET request.

Content-length is returned by 1.3.23 after a HEAD request, as well:

[daleg <at> lithium]~>telnet . 80
Trying 0.0.0.0...
Connected to ..
Escape character is '^]'.
HEAD /~daleg/ HTTP/1.1
Host: elemental.org

HTTP/1.1 200 OK
Date: Tue, 12 Mar 2002 19:03:17 GMT
Server: Apache/1.3.23 (Unix) PHP/4.1.1
Last-Modified: Sun, 31 Oct 1999 22:01:07 GMT
ETag: "97915-112e-381cbc23"
Accept-Ranges: bytes
Content-Length: 4398
Content-Type: text/html

/dale
Permalink | Reply | 0 comments |
headers
Bill Stoddard | 12 Mar 2002 22:57

[PATCH] mod_mem_cache using apr_atomic_dec()

I hesitate to commit the because I am not sure if apr_atomic_dec will be portable and
usable on enough OS/hardware combinations. mod_mem_cache could have several thousand
entries, so an apr_atomic_dec() that uses a lock per protected variable would not be too
cool...

If any apr_atomic_* implementations have hardware dependencies (ie, the implementation
explicitly exploits hardware features via assembly language calls for instance),
supporting the atomic operations in APR could become a real nightmare.  APR compiled on
one machine may not run on another machine even if the OS level of the two machines is
identical. Most gnarley...

Comments?

Bill

Index: mod_mem_cache.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_mem_cache.c,v
retrieving revision 1.32
diff -u -r1.32 mod_mem_cache.c
--- mod_mem_cache.c 12 Mar 2002 03:00:35 -0000 1.32
+++ mod_mem_cache.c 12 Mar 2002 21:44:55 -0000
 <at>  <at>  -61,6 +61,7  <at>  <at> 
 #include "mod_cache.h"
 #include "ap_mpm.h"
 #include "apr_thread_mutex.h"
+#include "apr_atomic.h"

 #if !APR_HAS_THREADS
 #error This module does not currently compile unless you have a thread-capable APR.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Trawick | 12 Mar 2002 23:29

dumb questions on a couple of the current 2.0 showstoppers

1)  * If any request gets to the core handler, without a flag that this 
      r->filename was tested by dir/file_walk, we need to 500 at the very 
      end of the ap_process_request_internal() processing.  This provides
      authors of older modules better compatibility, while still improving
      the security and robustness of 2.0.

    True or false: This refers to an issue where some broken module
                   causes the core dir walk to be skipped yet the
                   request gets to default handler.

    If true: Why is this a showstopper?  Broken modules cause all sorts
             of problems.  If this actually needs to be fixed, it can
             be fixed at any time.

    Either way: Any feedback on the comments that JimJag and I put in
                the STATUS file?

                Is this issue any more complicated than setting a flag
                in the last several "return OK" paths in
                ap_directory_walk() and in default_handler() to return
                HTTP_FORBIDDEN if the flag isn't set?

2)  * API changes planned for 2.0 that should happen before the
      GA release:
          * Free lists for bucket allocation
          * Pool allocator change

    Can anybody comment on the current status of either of these?  Is
    there work available for the masses to do?  Can we get the API
    changes committed Real Soon Now even if the new behavior isn't yet
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cliff Woolley | 12 Mar 2002 23:57
Favicon

Re: dumb questions on a couple of the current 2.0 showstoppers

On Tue, 12 Mar 2002, Jeff Trawick wrote:

> 2)  * API changes planned for 2.0 that should happen before the
>       GA release:
>           * Free lists for bucket allocation
>           * Pool allocator change
>
>     Can anybody comment on the current status of either of these?

The pool allocator change is done AFAIK -- Sander, are there any other
changes that need to be made above the ones in the patch you sent me?  If
not, please go ahead and commit.

The bucket freelist change was kind of waiting on the pool allocator
change, but the API change part can go ahead and get committed as is
without the pool change--it would just be a wrapper around malloc until
the pool change is done, at which point the freelist allocator can be
dropped in.

When I get back to Charlottesville on Thursday I'll finish up and commit
whatever part of the buckets change I can depending on the pool patch
status.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley <at> yahoo.com
   Charlottesville, VA
(Continue reading)

Permalink | Reply | 2 comments |

Gmane