Aryeh Katz wrote:
Stas Bekman wrote:
Actually it's not only about \n and \t, it's about other chars as
well. Now I get error messages like this:
This is just my opinion, but isn't this much to place in your error log?
Is this something you want your random sys admin to parse?
Why don't you hav
Stas Bekman wrote:
Actually it's not only about \n and \t, it's about other chars as well.
Now I get error messages like this:
This is just my opinion, but isn't this much to place in your error log?
Is this something you want your random sys admin to parse?
Why don't you have a separate mod_p
André Malo wrote:
* Stas Bekman <[EMAIL PROTECTED]> wrote:
Yes, but we use it to log error messages which aren't under our control.
e.g. from user's programs, like cgi scripts. what are we supposed to do?
parse and split a multiline message and invoke the logger n times?
post processing, (which
Brian Akins wrote:
>
> We had something similar. What we did that works is:
>
> UseCanonicalName On
> Listen 80
> Listen 8080
> ServerName www.domain.com:80
>
>
> So redirects, no matter what port they came in one, get redirected to
> port 80. This was our desired effect.
>
Under 1.3??
--
On Dec 19, 2003, at 1:35 PM, William A. Rowe, Jr. wrote:
Let me be clear (on the 1.3 side)...
one expects that given;
UseCanonicalName Off
Listen 8080
Port 80
an inbound request with a Host header of foo:80 would respond with
the redirection http://foo:80/
It does not. The Listen port again appl
William A. Rowe, Jr. wrote:
UseCanonicalName Off
Listen 8080
Port 80
an inbound request with a Host header of foo:80 would respond with
the redirection http://foo:80/
It does not. The Listen port again applies until you turn UseCanonicalName On.
We had something similar. What we did that works i
At 11:16 AM 12/19/2003, Tony Finch wrote:
>On Fri, Dec 19, 2003 at 10:04:15AM -0600, William A. Rowe, Jr. wrote:
>>
>> UseCanonicalName Off, Host: header provided (HTTP/1.1)
>>
>> The host name header *excluding the host header port suffix * of the request
>> is concatenated to httpd 1.3's Po
1.3.29-dev actually changes the determination of the port value
with UCN off in effect.
The big question is if the client does NOT send a Host
header, and UCN is Off, should the port be the port
number used in the connection socket OR should we use
whatever Port is set to... The current implementat
On Fri, Dec 19, 2003 at 10:04:15AM -0600, William A. Rowe, Jr. wrote:
>
> UseCanonicalName Off, Host: header provided (HTTP/1.1)
>
> The host name header *excluding the host header port suffix * of the request
> is concatenated to httpd 1.3's Port directive setting or the real port number
>
In both Apache 1.3 and 2.0 the UseCanonicalName doesn't work quite as it's
documented. The question would be, do we fix it or document it...
When requesting a document that results in a redirection (directory not
decorated by a trailing backslash, etc) the redirected server name doesn't
actually
* Stas Bekman <[EMAIL PROTECTED]> wrote:
> Yes, but we use it to log error messages which aren't under our control.
> e.g. from user's programs, like cgi scripts. what are we supposed to do?
> parse and split a multiline message and invoke the logger n times?
post processing, (which was actually
André Malo wrote:
* Stas Bekman <[EMAIL PROTECTED]> wrote:
This change:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.127.2.4&r2=1.127.2.5&diff_format=h
now escapes \n and \t chars. Why in the world would you do that? How are we
supposed to work with multilined and formatted with
* Stas Bekman <[EMAIL PROTECTED]> wrote:
> This change:
> http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.127.2.4&r2=1.127.2.5&diff_format=h
> now escapes \n and \t chars. Why in the world would you do that? How are we
> supposed to work with multilined and formatted with \t data?
> + *) SECURITY - verification as to wether the nonce returned in the
> + client response is one we issued ourselves by means of a
> + AuthNonce secret exposed as an md5(). See mod_digest documentation
> + for more details. The experimental/mod_auth_digest.c does not
> + have this
On Thu, 18 Dec 2003, Greg Marr wrote:
> Couldn't the new member be placed at the end of the request rec so
> that it's only a minor bump?
Sure - does that work across all compilers ? Or do some still do some
sort of sorting/packing depending on O level ?
Dw
This change:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.127.2.4&r2=1.127.2.5&diff_format=h
now escapes \n and \t chars. Why in the world would you do that? How are we
supposed to work with multilined and formatted with \t data?
__
16 matches
Mail list logo
