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.]
> 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
> 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
unteste
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
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 writ
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 CASE_BLIND_FILESYSTEM
> 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 correctl
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
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
> > 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
> 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
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.fi
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
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 the
> > 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 ca
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
file.h
18 matches
Mail list logo
