Re: [PATCH] mod_speling
Committed to trunk. -wsv On Jun 14, 2006, at 12:27 AM, olivier Thereaux wrote: On 9 Jun 2006, at 02:21, Wilfredo Sánchez Vega wrote: This looks fine, but can you add a patch to the docs? The feature isn't useful if nobody knows it's there. Sure. The patch is attached in this mail, but if I understand correctly, it should rather be sent to [EMAIL PROTECTED] ? How about translations? Is there any process to ensure that the localized versions will remain up to date? Or should I take care of that, too? Thanks, -- olivier patch_docs_mod_speling.patch
Re: [PATCH] mod_speling
This looks fine, but can you add a patch to the docs? The feature isn't useful if nobody knows it's there. Thanks, -wsv On May 30, 2006, at 4:30 PM, olivier Thereaux wrote: Hello, This is a followup to a (very) old thread about mod_speling on the httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/23.mbox/% [EMAIL PROTECTED] On Fri, Mar 03, 2000, Hugo Haas wrote: On Fri, Mar 03, 2000, Martin Kraemer wrote: On Thu, Mar 02, 2000 at 04:22:36PM -0500, Bruce R Miller wrote: [..] Our thought was to add an option, (CheckSpelling CaseOnly, instead of CheckSpelling on, or ...) that would have it automatically redirect _only_ if it were a case correction Yes, the proposal to even restrict the functionality to case correction ONLY has been suggested a while ago. I would welcome this, too, because mod_speling can be misused to poke around and look what other file are there I coded that some time ago. I will send you the patch as soon as I find it. :-) It appears that patch was never sent to the apache developers' community, but we have actually been using it on the W3C Web site for many years, where it has allowed us to enable mod_speling for user convenience, without creating too huge a volume of phantom URIs. I have recently dug up the patch, and adapted it for each major version of the apache httpd server (based on the sources for the 1.3.6, 2.0.58 and 2.2.2 releases). The three patch files are attached to this mail. Would it be possible to have these applied to the code tree? If so, I guess there would be documentation changes, as well, and I would be more than happy to help with those, too. Kind regards, olivier. -- olivier Thereaux - W3C - http://www.w3.org/People/olivier/ W3C Open Source Software: http://www.w3.org/Status mod_speling_1_3_36.patch mod_speling_2_0_58.patch mod_speling_2_2_2.patch
Re: [PATCH] Rename to Apache D
+1 so long as HTTP is actually getting removed from core. -wsv On Dec 14, 2005, at 12:21 PM, Paul Querna wrote: The attached patch is just a start, fixing the configure.in to generate the correct binary name by default. -Paul Index: configure.in === --- configure.in(revision 355792) +++ configure.in(working copy) @@ -527,7 +527,7 @@ AC_ARG_WITH(program-name, APACHE_HELP_STRING(--with-program-name,alternate executable name),[ progname=$withval ], [ - progname=httpd] ) + progname=d] ) # SuExec parameters AC_ARG_WITH(suexec-bin, smime.p7s Description: S/MIME cryptographic signature
Re: [vote] 2.2.0 tarballs
+1 on Mac OS. -wsv On Nov 28, 2005, at 11:55 PM, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. I am sorry for the confusion on whole move of 2.1.10 to 2.2.0. This entire situation is completely undefined in our VERSIONING file, and hasn't ever happened before with these versioning rules. I believe the best way to move forward for everyone is to vote on these 2.2.0 tarballs. Hopefully we can all learn from this, and come up with a better VERSIONING policy by the time we do 2.4. Thanks, Paul.
Some RFC 2616 questions
The spec for If-{None-}Match and If-{Un}Modified-Since is driving
me batty.
The biggest item has to do with having to know the response code
for the request without processing the request. Specifically, 14.24
(If-Match) and the others have a requirement like:
If the request would, without the If-Match header field,
result in
anything other than a 2xx status, then the If-Match header
MUST be
ignored.
This implies that we have to attempt the request, check the
status, and act on the If-Match header only if the request resulted
in an non-error status. That seems rather expensive for the server.
For example, if we have a GET request that recomputes uncached data
or something like that.
Furthermore, for many operations, such as PUT, COPY, MOVE and
DELETE, we'd have to back out the successful operation, since I might
not know that PUT will fail without actually trying it first.
Next up, 14.25 (If-Modified-Since) implies in the first paragraph
that it applies to all methods, but then only proceeds to describe
what to do with a GET, and even then, a GET with no Range header. If
I get an IMS for a PUT, is that a valid request? How about a DAV
COPY? Presumably in that case would apply, if valid, to the source
resource, not the destination.
-wsv
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] typo in manual
On HEAD and 2.2. Thanks, -wsv On Aug 9, 2005, at 7:36 AM, Ben Collins-Sussman wrote: [[[ Fix typo in manual. * docs/manual/logs.xml: typo. flexibly--flexible. ]]] Index: docs/manual/logs.xml === --- docs/manual/logs.xml(revision 231041) +++ docs/manual/logs.xml(working copy) @@ -425,7 +425,7 @@ /example pAlthough we have just shown that conditional logging is very - powerful and flexibly, it is not the only way to control the + powerful and flexible, it is not the only way to control the contents of the logs. Log files are more useful when they contain a complete record of server activity. It is often easier to simply post-process the log files to remove requests smime.p7s Description: S/MIME cryptographic signature
EAGAIN on write after poll() on Darwin (re: commit r160348)
Mike Smith tells me that it's possible for poll() to tell you that
a socket is writable and for the socket to change to an unwritable
state before you get around to writing to it for a number of
reasons. So it's reasonable (but presumably uncommon) to do a poll()
then get back EAGAIN when you subsequently try to write(). Which
implies that it may not be a bug in the OS after all.
If so, then the question is whether the correct fix would be in
APR instead of in HTTPd, since HTTPd isn't really aware here that
it's dealing with a non-blocking socket.
Does this make sense?
-wsv
On Apr 14, 2005, at 12:02 PM, Wilfredo Sánchez Vega wrote:
We're investigating possible issues in the system. One comment
from a kernel developer:
We are returning EWOULDBLOCK because the socket is in non-
blocking.
Inspecting the socket, so_state is 0x182 (0x100 is SS_NBIO).
Setting
a breakpoint on soioctl for SS_NBIO I can clearly see that httpd
is setting the socket as non-blocking. httpd is using fcntl which
translate the non-blocking change to an soioctl.
Does it make sense that the socket is non-blocking?
-wsv
On Apr 7, 2005, at 7:00 AM, Paul Querna wrote:
Jeff Trawick wrote:
On Apr 6, 2005 8:22 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Author: wsanchez
Date: Wed Apr 6 17:22:29 2005
New Revision: 160348
URL: http://svn.apache.org/viewcvs?view=revrev=160348
Log:
In emulate_sendfile(), handle APR_EAGAIN from apr_socket_send().
-rv = apr_socket_send(c-client_socket, buffer[o],
bytes_sent);
-*nbytes += bytes_sent;
-if (rv == APR_SUCCESS) {
-sendlen -= bytes_sent; /* sendlen != bytes_sent
== partial write */
-o += bytes_sent; /* o is where we are in
the buffer */
-togo -= bytes_sent;/* track how much of the
file we've sent */
+if (rv == APR_SUCCESS sendlen) {
+while ((rv == APR_SUCCESS || rv == APR_EAGAIN)
sendlen) {
Why would EAGAIN be returned? There should be a timeout set on the
APR socket. Either the send works within the timeout period or
we get
timeout error or we get some lower-level socket error.
If EAGAIN is really returned, I suspect there is something else
to investigate.
Yes, I was talking to wsanchez on IRC, and I suspect there might
be a bug in the OS-X kernel, causing a blocking socket to return
EAGAIN on write().
smime.p7s
Description: S/MIME cryptographic signature
Re: svn commit: r160348 - httpd/httpd/trunk/server/core_filters.c
We're investigating possible issues in the system. One comment
from a kernel developer:
We are returning EWOULDBLOCK because the socket is in non-blocking.
Inspecting the socket, so_state is 0x182 (0x100 is SS_NBIO).
Setting
a breakpoint on soioctl for SS_NBIO I can clearly see that httpd
is setting the socket as non-blocking. httpd is using fcntl which
translate the non-blocking change to an soioctl.
Does it make sense that the socket is non-blocking?
-wsv
On Apr 7, 2005, at 7:00 AM, Paul Querna wrote:
Jeff Trawick wrote:
On Apr 6, 2005 8:22 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Author: wsanchez
Date: Wed Apr 6 17:22:29 2005
New Revision: 160348
URL: http://svn.apache.org/viewcvs?view=revrev=160348
Log:
In emulate_sendfile(), handle APR_EAGAIN from apr_socket_send().
-rv = apr_socket_send(c-client_socket, buffer[o],
bytes_sent);
-*nbytes += bytes_sent;
-if (rv == APR_SUCCESS) {
-sendlen -= bytes_sent; /* sendlen != bytes_sent
== partial write */
-o += bytes_sent; /* o is where we are in
the buffer */
-togo -= bytes_sent;/* track how much of the
file we've sent */
+if (rv == APR_SUCCESS sendlen) {
+while ((rv == APR_SUCCESS || rv == APR_EAGAIN)
sendlen) {
Why would EAGAIN be returned? There should be a timeout set on the
APR socket. Either the send works within the timeout period or we
get
timeout error or we get some lower-level socket error.
If EAGAIN is really returned, I suspect there is something else to
investigate.
Yes, I was talking to wsanchez on IRC, and I suspect there might be
a bug in the OS-X kernel, causing a blocking socket to return
EAGAIN on write().
smime.p7s
Description: S/MIME cryptographic signature
