headers
bugzilla | 1 May 2011 09:15
Picon
Favicon

Bug report for Apache httpd-2 [2011/05/01]

+---------------------------------------------------------------------------+
| Bugzilla Bug ID                                                           |
|     +---------------------------------------------------------------------+
|     | Status: UNC=Unconfirmed NEW=New         ASS=Assigned                |
|     |         OPN=Reopened    VER=Verified    (Skipped Closed/Resolved)   |
|     |   +-----------------------------------------------------------------+
|     |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
|     |   |           MIN=Minor   NOR=Normal    ENH=Enhancement TRV=Trivial |
|     |   |   +-------------------------------------------------------------+
|     |   |   | Date Posted                                                 |
|     |   |   |          +--------------------------------------------------+
|     |   |   |          | Description                                      |
|     |   |   |          |                                                  |
| 7483|Ass|Enh|2002-03-26|Add FileAction directive to assign a cgi interpret|
| 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity            |
| 9945|New|Enh|2002-06-18|[PATCH] new funtionality for apache bench         |
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11294|New|Enh|2002-07-30|desired vhost_alias option                        |
|11580|Opn|Enh|2002-08-09|generate Content-Location headers                 |
|12033|Opn|Nor|2002-08-26|Graceful restart immidiately result in [warn] long|
|12680|New|Enh|2002-09-16|Digest authentication with integrity protection   |
|13029|New|Nor|2002-09-26|Win32 mod_cgi failure with non-ASCII characters in|
|13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst|
|14922|Inf|Enh|2002-11-28|<target> is currently hardcoded to 'apache2'      |
|15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne|
|16057|Ass|Maj|2003-01-14|module fails to init client_rmm and applies too ma|
|16126|Opn|Nor|2003-01-15|cache mishandles If-None-Match                    |
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Jagielski | 1 May 2011 16:09
Favicon

Re: mpm worker/mpm event: Revert an old (~10yr) change to the fd Q

Can you apply the patch and see if it fixes the problems??
"We think" is hardly sufficient "proof" that it does...

On Apr 29, 2011, at 11:43 AM, David Dabbs wrote:

> Hello.
> 
> The first "Patch Proposed To Backport from Trunk" in 2.2.x trunk STATUS is:
> 
>  * mpm worker/mpm event: Revert an old (~10yr) change to the fd Q; 
>    move back to FIFO rather than LIFO, for more consistent performance
>    so that older requests don't suffer
>    Trunk patch (applies for worker):
> http://svn.apache.org/viewvc?view=revision&revision=1064269
>    2.2.x patch (for event):
> http://people.apache.org/~igalic/patches/event-mpm-fdqueue.patch
> 
> I'd like to put in a vote for this to be applied to 2.2.x (2.2.18). 
> We think we're seeing performance anomalies similar to those referenced in
> the 
> discussion threads regarding these patches. 
> 
> 
> Thank you,
> 
> David
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Covener | 2 May 2011 04:40
Picon
Gravatar

Re: "RewriteRule ... /$1" considered harmful

> - Create new directives RewriteToPath, RewriteToURL that don't do guessing.
> - Document clearly the problems that may be caused by the guessing
> behaviour of RewriteRule. Maybe even mark RewriteRule as deprecated in
> 2.4.
>

another one on users <at> , +1 to this approach and strong advice in the
manual to use one of the other flavors.

Rewriterule in per-server context could emit a once-per-restart
warning if it interprets a substitution as a filesystem path.  If it
triggers a 403 from <Directory /> inadvertently, it will precede the
"permission denied by server configuration" in the error log.
Permalink | Reply | 5 comments |
headers
Eric Covener | 2 May 2011 06:04
Picon
Gravatar

Re: "RewriteRule ... /$1" considered harmful

On Sun, May 1, 2011 at 10:40 PM, Eric Covener <covener <at> gmail.com> wrote:
>> - Create new directives RewriteToPath, RewriteToURL that don't do guessing.
>> - Document clearly the problems that may be caused by the guessing
>> behaviour of RewriteRule. Maybe even mark RewriteRule as deprecated in
>> 2.4.
>>
>
> another one on users <at> , +1 to this approach and strong advice in the
> manual to use one of the other flavors.
>
> Rewriterule in per-server context could emit a once-per-restart
> warning if it interprets a substitution as a filesystem path.  If it
> triggers a 403 from <Directory /> inadvertently, it will precede the
> "permission denied by server configuration" in the error log.
>

I took a pass at the doc to make the stuff we're discussing a bit more
explicit which might help the discussion/deprecation too.

http://people.apache.org/~covener/patches/rewrite-substitution_clarity.diff

I think the DocumentRoot-relative substitution should not be preserved
in the RewriteToURL -- seems like an unnecessary complication.  IMO
RewriteToURL implies PT just like per-directory, however this comes
with some baggage -- exposing yourself to loops and losing the
intuitive use of the  L flag.

--

-- 
Eric Covener
covener <at> gmail.com
(Continue reading)

Permalink | Reply | 3 comments |
headers
André Malo | 2 May 2011 07:57
Picon

Re: "RewriteRule ... /$1" considered harmful

* Stefan Fritsch wrote:

> My impression is that mapping to different URLs is by far the more
> frequent use case, but I may be wrong. A different idea would be
>
> - Create new directives RewriteToPath, RewriteToURL that don't do
> guessing. - Document clearly the problems that may be caused by the
> guessing behaviour of RewriteRule. Maybe even mark RewriteRule as
> deprecated in 2.4.

Why not flags to RewriteRule? like

RewriteRule ... /$1 [abs]

(or [rel]).

For compat reasons I'd keep the current behaviour without such a flag.

nd
--

-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: <http://pub.perlig.de/books.html#apache2>
Permalink | Reply | 0 comments |
headers
slawomir.janotta | 2 May 2011 11:26
Picon
Favicon

AW: Problem with DNS lookup caching in reverse proxy

Hi Igor and everybody :-)
Unfortunately, this is exactly what won't work for me.
The point is: In our case the remote address is still valid. The "old" node is not to be shut down so the
connection to it is technically still valid. Instead, the full qualified address if looked up via the
resolver now points to a "new" node. If I'm correct, in this case there won't be any error. And if there is a
lot of traffic on the connection, there also won't be any timeout and the connection will be happy
accessing the "old" node because it simply uses the stored ip-address and doesn't see any reason to
discard it. If I set ttl to say 1 second (way too small for me in fact) and the connection is accessed every
100ms, there is no way to timeout the connection. The only solution I can think of is to force the expiry
after a set timeout.
Having said that I would like to ask some additional help with implementing such a solution.
Unfortunately, I'm pretty new to Apache and have to work it out "the hard way". So far I have worked out how to
enable the additional parameter for the mod_proxy. I have done it by adding the setting dnsto (for DNS
timeout) to the structure proxy_worker in mod_proxy.h. The question is: where can I register the timeout
to be used and how do I force the worker to re-resolve the address.
Regards
Slawo.

-----Ursprüngliche Nachricht-----
Von: Igor Galić [mailto:i.galic <at> brainsware.org] 
Gesendet: Dienstag, 26. April 2011 23:45
An: dev <at> httpd.apache.org
Betreff: Re: Problem with DNS lookup caching in reverse proxy

----- Original Message -----
> Hello everybody,
> 
> I have tried to solve my issue by contacting the users <at>  mailing list
> but meanwhile I think this is the more appropriate list to address
> it.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nick Gearls | 2 May 2011 12:01
Picon

mod_proxy & headers

Hello,

It seems that some headers cannot be modified when mod_proxy sets them.
Ex: Content-Type - it is not possible to overwrite it with any of the 
following directives:
   AddType ...
   ForceType ...
   Header set ...

I suppose that mod_proxy runs later then mod_headers 5?).
Could this be clarified in the doc?

As a general note, wouldn't it be possible to get, for each directive, 
the phase where it runs, to be able to understand processing order 
between modules? For the moment, the only ways are a look in the code or 
a test.

Thanks

Nick
Permalink | Reply | 7 comments |
headers
Eric Covener | 2 May 2011 12:14
Picon
Gravatar

Re: mod_proxy & headers

On Mon, May 2, 2011 at 6:01 AM, Nick Gearls <nickgearls <at> gmail.com> wrote:
> Hello,
>
> It seems that some headers cannot be modified when mod_proxy sets them.
> Ex: Content-Type - it is not possible to overwrite it with any of the
> following directives:
>  AddType ...
>  ForceType ...
>  Header set ...

See "doc or fix ForceType for not-default-handler?" thread for a bit
of discussion [but not enough to figure out what to do!]
Permalink | Reply | 0 comments |
headers
Plüm, Rüdiger, VF-Group | 2 May 2011 12:28

RE: mod_proxy & headers


> -----Original Message-----
> From: Nick Gearls 
> Sent: Montag, 2. Mai 2011 12:01
> To: Development Apache
> Subject: mod_proxy & headers
> 
> Hello,
> 
> It seems that some headers cannot be modified when mod_proxy 
> sets them.
> Ex: Content-Type - it is not possible to overwrite it with any of the 
> following directives:
>    AddType ...
>    ForceType ...
>    Header set ...

Which version did you use where Header set Content-Type failed?
It does not work correctly before 2.2.12.

Regards

Rüdiger
Permalink | Reply | 0 comments |
headers
Nick Gearls | 2 May 2011 12:56
Picon

Re: mod_proxy & headers

It's indeed prior to 2.2.12. I assume the problem is solved.

However, what about the proposition to indicate for every module (or 
directive when needed) the phase it runs, to be able to determine 
interactions? I guess this shouldn't be difficult when you know the 
module. This could maybe even be generated automatically from the code?

And maybe also specific features, like SetEnv result that cannot be used 
by other modules whereas SetEnvIf result can.

This would be a major help in some cases.

Regards,

Nick

-------- Original Message --------
Subject: RE: mod_proxy & headers
Date: Mon, 2 May 2011 12:28:50 +0200
From: "Plüm, Rüdiger, VF-Group" <ruediger.pluem <at> vodafone.com>
Reply-To: dev <at> httpd.apache.org
To: <dev <at> httpd.apache.org>

> -----Original Message-----
> It seems that some headers cannot be modified when mod_proxy
> sets them.
> Ex: Content-Type - it is not possible to overwrite it with any of the
> following directives:
>    AddType ...
>    ForceType ...
(Continue reading)

Permalink | Reply | 4 comments |

Gmane