You might want to check OpenSSL to see if the session caching and resume is
part of that code base.
What happens if you go to another box and do a
curl -I http://www.yoursite.com/favicon.ico
and/or
curl -i http://www.yoursite.com/favicon.ico
[Try this on google or yahoo if you want to see what should happen.]
Issue 42665 fixes a long existing bug in httpd. A patch is included with
the issue. I would like to nominate it for inclusion in v2.2.5
http://issues.apache.org/bugzilla/show_bug.cgi?id=42665
Thank you for contributing! As Rüdiger already points out, we want
patches to go into the development trunk
Whenever someone is ready to test this patch and/or commit it to the
development trunk, please feel free.
I think it should be obvious that if patches are going to sit around
untested
Thanks for the pointer but this patch is not even contained
in trunk yet and as far as I remember the patch is only an
optimization (compared to a bug that makes a functionality
unusable). So I would guess that it misses the boat for 2.2.5.
The patch is not an optimization--it fixes a bug
Apache already gives priority to the clients with the fastest connection.
To user stand why this is so, you need to understand how TCP/IP flow control
works and how that interacts with the send(), recv() and select() system
calls, and with the network send and receive buffers on the server and the
Folks want their static
files to be owned by themselves, and not readable to random other
users on the same system, but also serve-able by Apache. There are
various user and group permission that can make this sort-of-but-not-
quite happen, because whatever you do, someone can write a
The attached patch is the final one and applies to 2.2.4?
Yes, that is the final patch. It is a diff from v.2.2.4.
The indentation might not be quite correct after applying that patch. Due
space-to-tab conversion issues with my editor, I had to do a diff -u -b,
and the patch is not correctly
Here's a proper diff, without the spacing issue. (It was actually a line
terminator issue, caused by editing the file under Windows.)
--- request.c-2.2.4 2007-06-14 06:47:44.850623600 -0400
+++ request.c 2007-06-13 21:34:01.659559100 -0400
@@ -931,12 +931,20 @@
#ifdef
Hello William,
Thanks for the suggestions. I have a fix that is pretty simple (and
therefore I hope, unlikely to break anything ;-). Later today, after I've
compiled and tested it on both Windows and Linux, I'll post it to the list.
Allen
server/request.c lines 930 to 940 currently read:
if (r-finfo.filetype
#ifdef CASE_BLIND_FILESYSTEM
(filename_len = canonical_len)
#endif
((opts.opts (OPT_SYM_OWNER | OPT_SYM_LINKS)) ==
OPT_SYM_LINKS))
{
thisinfo.filetype
Hm. This looks wrong to me. We should only allow RewriteRules
in the directory context if OPT_SYM_LINKS is set since we do
not do any check on the result of a RewriteRule with respect
to symlinks. So we cannot be sure that the result of the
RewriteRule fulfils the conditions promised by
if (r-finfo.filetype == APR_REG
(!r-path_info || !*r-path_info) )
Possible stupid question, but why do we need this path_info check?
ap_directory_walk uses r-path_info to hold the portion of the path that has
not yet been walked. The check on
After sending that last post, I realized that if the full path points to a
directory, it will do a final lstat even though it doesn't need to.
That's easy to fix. Here is the revised code, the revised patch, and test
output.
CODE:
if (r-finfo.filetype
#ifdef CASE_BLIND_FILESYSTEM
I hate to have to do this...
I realized that ++seg should only be incremented when the optimization
results in either a continue or a break. Here is the correction:
CODE:
if (r-finfo.filetype
#ifdef CASE_BLIND_FILESYSTEM
(filename_len = canonical_len)
#endif
When processing a GET /.../file.html, Apache httpd briefly treats
file.html as a directory and attempts to open
docroot/.../file.html/.htaccess. The os returns ENOTDIR,
and then
processing of the request continues.
Yes, this is a somewhat known issue. Previously it caused
issues
Reading resolve_symlink() in server/request.c, it first checks
OPT_SYM_LINKS. If OPT_SYM_LINKS is set, it never does the checks for link
ownership. It checks link ownership only when OPT_SYM_OWNER is set and
OPT_SYM_LINKS is unset.
Based on this logic, the following changes should be made to
Summary:
When processing a GET /.../file.html, Apache httpd briefly treats
file.html as a directory and attempts to open
docroot/.../file.html/.htaccess. The os returns ENOTDIR, and then
processing of the request continues.
There would seem to be no reason for httpd to attempt to open
18 matches
Mail list logo
