Re: AW: SSL_VERSION_LIBRARY
I have tested the patch and it works fine. Thanks a lot. On 12/09/07 13:14, Plüm wrote: > >> -Ursprüngliche Nachricht- >> Von: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] >> Gesendet: Mittwoch, 12. September 2007 09:47 >> An: dev@httpd.apache.org >> Betreff: Re: AW: SSL_VERSION_LIBRARY >> >> >> William A. Rowe, Jr. wrote: >> >>> William A. Rowe, Jr. wrote: >>> >>>> Looking at the scope of all these static calls, I really >>>> >> believe the >> >>>> patch is this simple (process->pool survives the entire httpd); >>>> >>> Sorry - scratch that. I wasn't counting the frequency of >>> >> pstrdup calls. >> >>> Just begging for optimization :) >>> >> Without fretting the optimizations, try this for the cleanest >> patch I could >> think of (remember, these are static internal functions) >> >> > > Also looks good for me. Thanks for working this out. > Mind to attach this patch to PR43334 > (https://issues.apache.org/bugzilla/show_bug.cgi?id=43334) > so that people there can test? > > Regards > > Rüdiger > > > -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED]Department of Mathematics tel:+972-54-4227607 Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
Re: SSL_VERSION_LIBRARY
Yes. This fixed the problem: Now I get SSL_VERSION_LIBRARY=OpenSSL/0.9.8e On 09/09/07 22:12, Ruediger Pluem wrote: > On 09/08/2007 08:40 PM, Zvi Har'El wrote: > >> Hi, >> >> I installed the new httpd 2.2.6 on several machines. One of them runs >> RedHat Enterprise Linux. Another is Solaris 2.9. When looking at the SSL >> environment variables in a simple CGI, I notticed that on the Linux machine, >> SSL_VERSION_LIBRARY is not set at all, and in the Solaris machine, it >> contains >> several lines from the apache magic files. >> > > This looks similar to PR 43334 > (https://issues.apache.org/bugzilla/show_bug.cgi?id=43334). > Could you please test my diagnostic patch from there? > > Regards > > Rüdiger > -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED]Department of Mathematics tel:+972-54-4227607 Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
SSL_VERSION_LIBRARY
Hi,
I installed the new httpd 2.2.6 on several machines. One of them runs
RedHat Enterprise Linux. Another is Solaris 2.9. When looking at the SSL
environment variables in a simple CGI, I notticed that on the Linux machine,
SSL_VERSION_LIBRARY is not set at all, and in the Solaris machine, it contains
several lines from the apache magic files.
SSL_VERSION_LIBRARY='---
--
# msword: file(1) magic for MS Word files
#
# Contributor claims:
# Reversed-engineered MS Word magic numbers
#
0 string \376\067\0\043 application/msword
0 string \333\245-\0\0\0 application/msword
# disable this one because it applies also to other
# Office/OLE documents for which msword is not correct. See PR#2608.
#0 string \320\317\021\340\241\261application/msword
#--
# printer: file(1) magic for printer-formatted files
#
# PostScript
0 string %! application/postscript
0 string \004%! application/postscript
# Acrobat
# (due to [EMAIL PROTECTED])
0 string %PDF- application/pdf
#--
# sc: file(1) magic for "sc" spreadsheet
#
38 string Spreadsheet application/x-sc
#--
# tex: file(1) magic for TeX files
#
# XXX - needs byte-endian stuff (big-endian and little-endian DVI?)
#
# From <[EMAIL PROTECTED]>
# Although we may know the offset of certain text fields in TeX DVI
# and font files, we can'\''t use them reliably because they are not
# zero terminated. [but we do anyway, christos]
0 string \367\002application/x-dvi
#0 string \367\203TeX generic font data
#0 string \367\131TeX packed font data
#0 string \367\312TeX virtual font data
#0 string This\ is\ TeX, TeX transcript text
#0 string This\ is\ METAFONT, METAFONT transcript text
# There is no way to detect TeX Font Metric (*.tfm) files without
# breaking them apart and reading the data. The following patterns
# match most *.tfm files generated by METAFONT or afm2tfm.
#2 string \000\021TeX font metric data
#2 string \000\022TeX font metric data
#>34string >\0 (%s)
# Texinfo and GNU Info, from Daniel Quinlan ([EMAIL PROTECTED])
#0 string \\input\ texinfoTexinfo source text
#0 string This\ is\ Info\ fileGNU Info text
# correct TeX magic for Linux (and maybe more)
# from Peter Tobias ([EMAIL PROTECTED])
#
0 leshort 0x02f7 application/x-dvi
# RTF - Rich Text Format
0 string {\\rtf application/rtf
#--
# animation: file(1) magic for animation/movie formats
#
# animation formats, originally from [EMAIL PROTECTED] (VaX#n8)
# MPEG file
0 string \000\000\001\263video/mpeg
#
#'
Do you have any idea what the problem might be? Both machine have the same
version of openssl, OpenSSL 0.9.8e 23 Feb 2007, and I have not found any
problems in the server otherwise.
Best,
Zvi.
--
Dr. Zvi Har'El mailto:[EMAIL PROTECTED]Department of Mathematics
tel:+972-54-4227607 Technion - Israel Institute of Technology
fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/Haifa 32000, ISRAEL
"If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
Saturday, 26 Elul 5767, 8 September 2007, 9:30PM
Re: overflow in mod_autoindex suspected - solaris - httpd 2.2.*
I Tried the two settings, independently: 1) changes the line "ForceType text/html" to "ForceType tex/plain" in my .htaccess. 2) put a line "EnableSendFile off" in my .htaccess (.htaccess is located at the parent directory of the directory which contains the 256 bytes header file). In the first case, I got in all the four accesses the correct response (omitting the HTTP headers) Index of /test_mod_auto_index/256 XXX XXX XXX XXX NameLast modified Size Description Parent Directory - 1 14-Jan-2007 14:110 2 14-Jan-2007 14:110 3 14-Jan-2007 14:110 KUKU14-Jan-2007 14:20 256 Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8d PHP/4.4.4 Server at mailto:[EMAIL PROTECTED]">www.math.technion.ac.il Port 80 In the second case, I got all the four accesses the correct response (omitting the HTTP headers) XXX XXX XXX XXX NameLast modified Size Description Parent Directory - 1 14-Jan-2007 14:110 2 14-Jan-2007 14:110 3 14-Jan-2007 14:110 KUKU14-Jan-2007 14:20 256 Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8d PHP/4.4.4 Server at mailto:[EMAIL PROTECTED]">www.math.technion.ac.il Port 443 The diffrence between the two responses comes from the fact that I have the setting "IndexOptions SuppressHTMLPreamble", which explains the extra lines before the X's if the Header is of type text/plain, lines which are suppressed if the Header is of type text/html. Since I need to use HeaderFile of mime type text/html (I use normally the .html extension and add the necessary HTML code), it seems the solution to the problem is to use in Solaris system the directive "EnableSendFile off" . Note that my document root is *not* network mounted. So, I suggest to add SOLARIS to the list of systems where sendfile should be disabled for files over 256 bytes! It is surprising that this problem is not exhibited in httpd 2.0.59, although this directive was introduced already in 2.0.44 according to the manual. In any case, thank you for pointing this directive to me. | Thanks, Zvi. | Ruediger Pluem wrote, On 18/01/07 21:55: > On 01/18/2007 01:28 PM, Zvi Har'El wrote: > >> I believe this is really a problem of the HTTP client protocol level. in >> HTTP/1.1 we get a failure, and HTTP/1.0 or HTTPS (1.1 or 1.0) success, >> for example: >> > > Could you please do the following tests independently: > > 1. Change the ForceType in your .htaccess to text/plain > 2. Add EnableSendFile off to your httpd.conf > > Please retest afterwards with all four accesses > > HTTP/1.0, HTTP/1.1, ssl and non ssl. > > Regards > > Rüdiger > -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED]Department of Mathematics tel:+972-54-4227607 icq:179294841Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
Re: overflow in mod_autoindex suspected - solaris - httpd 2.2.*
erated directory index, if the > >> 'HeaderName' file is 256 bytes or more, and it has mime type text/html, >> Apache returns an empty page. You can look at >> http://www.math.technion.ac.il/test_mod_auto_index/ for a >> demonstration. The same test on a RedHat Enterprise Linux 4 succeeds. >> >> Thanks, >> >> Zvi. >> > > > I have experienced the same problem with Apache 2.2.0 on Solaris 2.8. Would > not > have found a solution if not for this report. I have found that while I get a > blank index returned in MS IE 6 on Win2k, Netscape 7.1 in Win2k and Firefox > 1.5 > on Solaris 8, if I telnet into the server and GET a directory, the properly > formatted index is returned. I can also get a properly formatted index by > connecting with Netscape 4.76 on Solaris or Win2k. I worked around the > problem > using SSI with an shtml file containing only an include for a file containing > the original content of my HeaderName file and another for my ReadmeName > file. > The problem is exhibited with a ReadmeName file over 255 bytes as well. > Derek > derekcooper30[at]hotmail_dot_com > > > > -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED]Department of Mathematics tel:+972-54-4227607 icq:179294841Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
Re: overflow in mod_autoindex suspected - solaris - httpd 2.2.*
P.S. I found out that using SSL, the problems disappears. Try https://www.math.technion.ac.il/test_mod_auto_index/ . I have no clue why. Also, you can see a RHEL4 test in http://Gilead.org.il/test_mod_auto_index/ Zvi Har'El wrote, On 14/01/07 15:14: Hi Apache Developers, I a a web master of a Solaris 2.9 system for quite a number of years, and always use the most recent Apache version available. I am now using Apache 2.2.4, but the problem I describe below started with the 2.2.x branch. 2.0.59 doesn't have this problem. The problem that in an autogenerated directory index, if the 'HeaderName' file is 256 bytes or more, and it has mime type text/html, Apache returns an empty page. You can look at http://www.math.technion.ac.il/test_mod_auto_index/ for a demonstration. The same test on a RedHat Enterprise Linux 4 succeeds. Thanks, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED]Department of Mathematics tel:+972-54-4227607 icq:179294841Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
overflow in mod_autoindex suspected - solaris - httpd 2.2.*
Hi Apache Developers, I a a web master of a Solaris 2.9 system for quite a number of years, and always use the most recent Apache version available. I am now using Apache 2.2.4, but the problem I describe below started with the 2.2.x branch. 2.0.59 doesn't have this problem. The problem that in an autogenerated directory index, if the 'HeaderName' file is 256 bytes or more, and it has mime type text/html, Apache returns an empty page. You can look at http://www.math.technion.ac.il/test_mod_auto_index/ for a demonstration. The same test on a RedHat Enterprise Linux 4 succeeds. Thanks, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED]Department of Mathematics tel:+972-54-4227607 icq:179294841Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
missing variable in suexec safe list
Hi, I just noticed that the safe_env_list in suexec.c has one variable name missing: SERVER_SIGNATURE. Here is a tivial patch to add it: --- httpd-2.0.50/support/suexec.c.~20040209205949~ 2004-02-09 22:59:49.0 +0200 +++ httpd-2.0.50/support/suexec.c 2004-08-18 09:46:51.0 +0300 @@ -134,6 +134,7 @@ "SERVER_ADDR=", "SERVER_PORT=", "SERVER_PROTOCOL=", +"SERVER_SIGNATURE=", "SERVER_SOFTWARE=", "UNIQUE_ID=", "USER_NAME=", Please commit this to the CVS. Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED]Department of Mathematics tel:+972-54-4227607 icq:179294841Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Wednesday, 1 Elul 5764, 18 August 2004, 9:42AM
timefmt in mod_include
Dear Apache HTTPD developers, Apache sometimes suffers from the limitations of the OS it is built on. One such limitation is that the C-library in SOLARIS doesn't have the %z time format (numeric time zone), which is a GNU extension to strftime(3). It is required to emit RFC882 conformant dates, using . I feel it is important enough that this limitation should be checked in configure time and an implementation of strftime which supprts this extension is used. This is was done, for example, in the SOLARIS build of GNU awk, since GNU awk claims to supports this format and cannot do it with the native library alone. As a matter of fact, gawk implementors were pretty reluctent to do this, forcing on the user a special configuration flag, "--with-whiny-user-strftime". I don't wish to whine, but don't you suppose apache should have its own %z implementation? Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 icq:179294841 Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Thursday, 10 Nisan 5764, 1 April 2004, 5:41PM
AddCharset filename extensions (again)
Dear Apache developers, I sent the following three months ago, but since I got no response, and now 2.0.49 has been rolled without the patch, I resubmit it for you attention: The default httpd.conf includes the lines AddCharset ISO-8859-1 .iso8859-1 .latin1 AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen AddCharset ISO-8859-3 .iso8859-3 .latin3 AddCharset ISO-8859-4 .iso8859-4 .latin4 AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk However, quick look at http://www.iana.org/assignments/character-sets shows that calling the non-latin charsets ISO8859-N by the name latinN is wrong. For example, latin8 is ISO-8859-14, or iso-celtic, and certainly not ISO-8859-8, which is just hebrew! Similarly, latin6 is ISO-8859-10, and not ISO-8859-6, which is arabic! Finally, latin5 is ISO-8859-9, turkish, and not ISO-8859-5, which is cyrillic. latin1-4 are ok, and I didn't find latin7 in this reference at all. I suggest httpd.conf should be fixed accordingly. To make my point clearer, here is the patch: --- httpd-2.0.48/docs/conf/httpd-std.conf.in.~20031011014743~ 2003-10-11 03:47:43.0 +0200 +++ httpd-2.0.48/docs/conf/httpd-std.conf.in2003-12-15 18:47:07.0 +0200 @@ -797,11 +797,15 @@ AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen AddCharset ISO-8859-3 .iso8859-3 .latin3 AddCharset ISO-8859-4 .iso8859-4 .latin4 -AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru -AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb -AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk -AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb -AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk +AddCharset ISO-8859-5 .iso8859-5 .cyr .iso-ru +AddCharset ISO-8859-6 .iso8859-6 .arb +AddCharset ISO-8859-7 .iso8859-7 .grk +AddCharset ISO-8859-8 .iso8859-8 .heb +AddCharset ISO-8859-9 .iso8859-9 .latin5 .trk +AddCharset ISO-8859-10 .iso8859-10 .latin6 +AddCharset ISO-8859-13 .iso8859-13 .latin7 +AddCharset ISO-8859-14 .iso8859-14 .latin8 +AddCharset ISO-8859-15 .iso8859-15 .latin9 AddCharset ISO-2022-JP .iso2022-jp .jis AddCharset ISO-2022-KR .iso2022-kr .kis AddCharset ISO-2022-CN .iso2022-cn .cis I have also included latin7 and latin9, which for some reason absent from IANA, but appear as standard in in the FSF's "free recode". BTW, instead of inventing new charset abbreviations like .cyr, .arb, .grk, .heb, I would personally prefer using the IANA (RFC 1345) aliases: .cyrillic, .arabic, .greek, .hebrew, in the same way we use .latin1, .latin2 , etc, but this is a matter of opinion, not bug fix patching. Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 icq:179294841 Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Friday, 27 Adar 5764, 19 March 2004, 6:53PM
Re: AddCharset filename extensions
To make my point clearer, here is the patch: --- httpd-2.0.48/docs/conf/httpd-std.conf.in.~20031011014743~ 2003-10-11 03:47:43.0 +0200 +++ httpd-2.0.48/docs/conf/httpd-std.conf.in2003-12-15 18:47:07.0 +0200 @@ -797,11 +797,15 @@ AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen AddCharset ISO-8859-3 .iso8859-3 .latin3 AddCharset ISO-8859-4 .iso8859-4 .latin4 -AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru -AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb -AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk -AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb -AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk +AddCharset ISO-8859-5 .iso8859-5 .cyr .iso-ru +AddCharset ISO-8859-6 .iso8859-6 .arb +AddCharset ISO-8859-7 .iso8859-7 .grk +AddCharset ISO-8859-8 .iso8859-8 .heb +AddCharset ISO-8859-9 .iso8859-9 .latin5 .trk +AddCharset ISO-8859-10 .iso8859-10 .latin6 +AddCharset ISO-8859-13 .iso8859-13 .latin7 +AddCharset ISO-8859-14 .iso8859-14 .latin8 +AddCharset ISO-8859-15 .iso8859-15 .latin9 AddCharset ISO-2022-JP .iso2022-jp .jis AddCharset ISO-2022-KR .iso2022-kr .kis AddCharset ISO-2022-CN .iso2022-cn .cis I have also included latin7 and latin9, which for some reason absent from IANA, but appear as standard in in the FSF's "free recode". BTW, instead of inventing new charset abbreviations like .cyr, .arb, .grk, .heb, I would personally prefer using the IANA (RFC 1345) aliases: .cyrillic, .arabic, .greek, .hebrew, in the same way we use .latin1, .latin2 , etc, but this is a matter of opinion, not bug fix patching. On Sun, 14 Dec 2003 15:13:34 +0200, Zvi Har'El wrote about "AddCharset filename extensions": > The default httpd.conf includes the lines > > AddCharset ISO-8859-1 .iso8859-1 .latin1 > AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen > AddCharset ISO-8859-3 .iso8859-3 .latin3 > AddCharset ISO-8859-4 .iso8859-4 .latin4 > AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru > AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb > AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk > AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb > AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk > > However, quick look at http://www.iana.org/assignments/character-sets shows > that calling the non-latin charsets ISO8859-N by the name latinN is wrong. > For example, latin8 is ISO-8859-14, or iso-celtic, and certainly not > ISO-8859-8, which is just hebrew! Similarly, latin6 is ISO-8859-10, and not > ISO-8859-6, which is arabic! Finally, latin5 is ISO-8859-9, turkish, and not > ISO-8859-5, which is cyrillic. latin1-4 are ok, and I didn't find latin7 in > this reference at all. I suggest httpd.conf should be fixed accordingly. > > -- > Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics > tel:+972-54-227607 icq:179294841 Technion - Israel Institute of Technology > fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL > "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) > Sunday, 19 Kislev 5764, 14 December 2003, 3:03PM -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 icq:179294841 Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Monday, 21 Kislev 5764, 15 December 2003, 6:58PM
AddCharset filename extensions
The default httpd.conf includes the lines AddCharset ISO-8859-1 .iso8859-1 .latin1 AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen AddCharset ISO-8859-3 .iso8859-3 .latin3 AddCharset ISO-8859-4 .iso8859-4 .latin4 AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk However, quick look at http://www.iana.org/assignments/character-sets shows that calling the non-latin charsets ISO8859-N by the name latinN is wrong. For example, latin8 is ISO-8859-14, or iso-celtic, and certainly not ISO-8859-8, which is just hebrew! Similarly, latin6 is ISO-8859-10, and not ISO-8859-6, which is arabic! Finally, latin5 is ISO-8859-9, turkish, and not ISO-8859-5, which is cyrillic. latin1-4 are ok, and I didn't find latin7 in this reference at all. I suggest httpd.conf should be fixed accordingly. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 icq:179294841 Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Sunday, 19 Kislev 5764, 14 December 2003, 3:03PM
HTTPS env var in suexec
Hi, In apache_1.3.28, running a cgi with suEXEC has a problem to identify SSL connections using the normal enviroment HTTPS=on setting, since suexec.c in this distribution (in line 137) has in the safe variable list the string "HTTPS_" for a prefix, and doesn't have the string "HTTPS=". This has been fixed in apache 2, but can you please also fix it in apache 1.3? Thanks, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 icq:179294841 Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Tuesday, 28 Av 5763, 26 August 2003, 4:43PM
Re: proxy request handling bug?
On Mon, 22 Jul 2002 11:03:57 +0200, Graham Leggett wrote about "Re: proxy request handling bug?": > Koga Youichirou wrote: > > >I found that 1.3.26 and 2.0.39 without mod_proxy accept proxy requests > >and treat them as requsts to its URIs. > > > >Is this behavior right? > > As far as I am aware, yes. If an attempt is made to fetch data on a > virtual host not configured locally, Apache serves the default config. > > Remember that specifying the sitename in the URI after the GET is > (AFAIK) just as valid for normal webservers as it is for proxies. > To quote, if I may, from the RFC: To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Monday, 13 Av 5762, 22 July 2002, 12:10PM
Re: [RHSA-2002:103-13] Updated Apache packages fix chunked encoding issue
On Wed, 19 Jun 2002 19:57:00 -0400, [EMAIL PROTECTED] wrote about "[RHSA-2002:103-13] Updated Apache packages fix chunked encoding issue": > We have backported the security fix from the official Apache 1.3.26 > release. This should help minimize the impact of upgrading to our errata > packages. Hi, Since you have backported apache's implementation for ap_strtol, does this mean you suspect glibc's strtol? I believe the latter sets ERANGE correctly, therefore the whole business of replacing strtol by ap_strtol everywhere doen't make sense. The only real fix is the patch of http_protocol.c, where *atol* is replaced by strtol. (of course redhats' apache_1.3.23-chunky.patch does other, unrelated stuff). Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Sunday, 13 Tammuz 5762, 23 June 2002, 5:10PM
Is Apache Proxy Half-Duplex?
Hello, Experimenting with an Apache Proxy, I noticed that in version 1.3 (the latest cvs snapshot) it behaves in a half-duplex fashion. That is, it doesn't read the backend server response until it have finished transmitting the client's request body. This is pretty annoying, mainly if the request involves a very large post (file upload), and the backend sever response, after the headers, says "Please wait patiently...". I wonder: are there any intentions to change this? It seems that full-duplex operation requires two threads per proxy, which is not how the Apache proxy server works. Is the situation different, or going to be different, in Apache 2? Just for reference, the Squid proxy doesn't suffer from this deficiency. Thanks for you attention, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Wednesday, 12 Sivan 5762, 22 May 2002, 6:03PM
[PATCH] Re: proxy_cache handles "304 Not Modified" incorrectly
Dear Graham,
To make a long discusion short, I hereby insert my 3-liner patch (for
apache_1.3.24) for the problem. You'll be the judge.
--- proxy_cache.c.orig Wed Mar 13 23:05:32 2002
+++ proxy_cache.c Tue May 7 19:04:28 2002
@@ -1477,6 +1477,11 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, r->server, "Expiry date
calculated %ld", (long)expc);
}
+/* Strip Content-Length from 304 reponse, in case buggy IIS-5.0 sends it! */
+if (r->status == HTTP_NOT_MODIFIED) {
+ ap_table_unset(resp_hdrs, "Content-Length");
+}
+
/* get the content-length header */
clen = ap_table_get(resp_hdrs, "Content-Length");
if (clen == NULL)
On Tue, 07 May 2002 18:38:49 +0300, Zvi Har'El wrote about "Re: proxy_cache handles
"304 Not Modified" incorrectly":
> On Tue, 07 May 2002 09:44:05 +0200, Graham Leggett wrote about "Re: proxy_cache
>handles "304 Not Modified" incorrectly":
> > How many versions of IIS v5.0 (ie which service packs) are giving this
> > error? If it's fixed in a further service pack, then that should be the
> > encouraged solution.
>
> This is the most recent version of IIS which gives this error. No service pack
> on it.
--
Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics
tel:+972-54-227607 Technion - Israel Institute of Technology
fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL
"If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
Tuesday, 26 Iyyar 5762, 7 May 2002, 7:06PM
Re: proxy_cache handles "304 Not Modified" incorrectly
On Tue, 07 May 2002 09:44:05 +0200, Graham Leggett wrote about "Re: proxy_cache handles "304 Not Modified" incorrectly": > How many versions of IIS v5.0 (ie which service packs) are giving this > error? If it's fixed in a further service pack, then that should be the > encouraged solution. This is the most recent version of IIS which gives this error. No service pack on it. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Tuesday, 26 Iyyar 5762, 7 May 2002, 6:37PM
Re: proxy_cache handles "304 Not Modified" incorrectly
On Mon, 06 May 2002 10:09:02 -0700, Joshua Slive wrote about "Re: proxy_cache handles "304 Not Modified" incorrectly": > On Mon, 6 May 2002, Cliff Woolley wrote: > > Hmmm One quote is > > >If a cache uses a received 304 response to update a cache entry, the >cache MUST update the entry to reflect any new field values given in >the response. > Let me start by saying that RFC 2068 is *obsolete*. The reigning RFC is now 2616. Here are two quotes: 10.3.5 304 Not Modified If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields. The response MUST include the following header fields: - Date, unless its omission is required by section 14.18.1 If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly. - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. 7.1 Entity Header Fields Entity-header fields define metainformation about the entity-body or, if no body is present, about the resource identified by the request. Some of this metainformation is OPTIONAL; some might be REQUIRED by portions of this specification. entity-header = Allow; Section 14.7 | Content-Encoding ; Section 14.11 | Content-Language ; Section 14.12 | Content-Length ; Section 14.13 | Content-Location ; Section 14.14 | Content-MD5 ; Section 14.15 | Content-Range; Section 14.16 | Content-Type ; Section 14.17 | Expires ; Section 14.21 | Last-Modified; Section 14.29 | extension-header extension-header = message-header The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields SHOULD be ignored by the recipient and MUST be forwarded by transparent proxies. The RFC tells you exactly which headers may be sent with a 304 Not modified reply, and which are not. Logically, if an object is not modified, none of its intrinsic properties, like length, last modified type, content type, etc. cannot be changed. On the other hand, it is possible that the expiration of an object may be extended without changing it. I think that the IIS bug is a result of a code which sends explanatory HTML text with error replies, which in this case shouldn't be send. The "Content-Length" they specify is the length of the empty body, not the length of the entity!!!. Of course, we don't need to fix all IIS bugs, but we should behave reasonably: Whatever garbage headers the server sends, we should only use the valid ones, and ignore the others, if we can. The fix is not hard, and it will just improve the apache's proxy quality, rather then just blame the bad guy. Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Tuesday, 25 Iyyar 5762, 7 May 2002, 3:41PM
proxy_cache handles "304 Not Modified" incorrectly
Dear Apache developers, I have noticed today that when Microsoft-IIS/5.0 sends a "304 Not Modified" response to IMS GET request, it (incorrectly IMHO) sends with it a "Content-Length: 0" header. This is (again IMHO) a bug in IIS, but because of that, IMS GET request with "Pragma: no-cache" headers are not handled correctly: When the cache revalidation is done, in ap_proxy_cache_update(), the content length is reset (in line 1481 in apache_1.3.24, line 1508 in the current snapshot of apache_1.3.25-dev, file proxy_cache.c), before the status is checked to be HTTP_NOT_MODIFIED (in line 1513 or 1547 resp). This makes the erroneous Content-Length: 0 header replace the real length in the cache file headers, and the file is destroyed. Not this doesn't happen without the "Pragma: no-cache" header. A possible fix would be do ignore the "Content-Length" in the response in case of "304 Not Modified", but I think that perhaps no header in such a response should replace the cached headers! Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Monday, 25 Iyyar 5762, 6 May 2002, 6:42PM
Re: [PATCH] mod_deflate
On Fri, 15 Feb 2002 09:44:19 -0800, Ian Holsman wrote about "Re: [PATCH] mod_deflate": > > > I'm still not very happy about compressing EVERYTHING and excluding > certain browsers > as you would have to exclude IE & Netscape. > > so > this is a > -1 for this patch. > in order to change this checks need to be there with a directive to > ignore them (default:off) > IMHO, deflating everything is a waste of the computer resources. HTML files really compress well. But most of the image files currently supported, e.g., PNG, GIF, JPEG are already compressed, and deflating them will really do nothing -- just spend your CPU. I think that compressing text/html for browsers who send "Accept-Encoding: gzip" is the right approach. A possible enhancement is to have a directive (DeflateAddMimeType) which will enable deflating more mime types, e.g., text/plain, but these are really rare! Another type which is worth compressing is application/postscript, since many viewers (I am not an expert which - at least those decendents of GhostScript) are capable of viewing gzipped postscript files. The problem with that is that this is not a function of the browser, which cannot handle such files, but a function of the viewer, so the required "Accept-Encoding: gzip" doesn't prove anything about the ability of the external viewer! To summerize, I suggest to deflate only types which can be handled by the browser itself, and which are not already compressed, which amounts to text/html or more generally text/* (text/css for instance). Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Saturday, 4 Adar 5762, 16 February 2002, 9:21AM
unexplained phenonmenon: hanging apache processes (fwd)
Dear friends, Nadav, my son, sent the enclosed message to the Apache's users mailing list, and drew blank. I resend it here, hoping the top Apache gurus participating in the discussions here may give some insight. We are really puzzled by the described behavior. Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Thursday, 25 Shevat 5762, 7 February 2002, 1:39PM -- Forwarded message -- Date: Sun, 20 Jan 2002 13:28:09 +0200 From: Nadav Har'El <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: unexplained phenomenon: hanging apache processes Resent-Date: Thu, 7 Feb 2002 11:00:23 +0200 Resent-From: [EMAIL PROTECTED] Resent-To: "Zvi Har'El" <[EMAIL PROTECTED]> Recently I've stumbled a puzzling problem when trying to measure Apache's performance using Microsoft's WAS (Web Application Stress Tool) or Radview's WebLOAD. I was wondering if anyone ever noticed this phenomenon, or can suggest an explanation, and any guess on whether this is a bug in Apache (or Linux), or what. The problem is that something in the measurement client, the server OS (I tried Linux 2.2.16, 2.2.19 and 2.4.3), Apache (I tried 1.3.20), or modssl (I tried both without it and with it) - something causes one or more of the httpd processes to "hang", blocking on reading input from the client which will never come. Such a blocking process will remain blocked for 300 seconds (or another period defined by the Apache "Timeout" directive), so over time more and more processes can get hung; On WebLOAD measurements with very high loads, starting apache with 250 processes, we consistently got them all blocked after roughly 10 minutes, at which point Apache's throughput obviously dropped down to zero. But it is even easier to recreate this problem when Apache is limited (with MaxClients) to a smaller number of processes: For example with 9 processes Webload will hang them all in a few minutes, and with 2 processes Microsoft WAS will hang them both (if you configure it to do SSL requests) almost immediately. I tried several experiments to understand what is going on, but so far without being able to fully explain it, so I was hoping maybe someone else noticed this problem and can shed some light on it (or just say "I've seen it too!"). For example, when I measure Apache with one process (http -X) with MS-WAS and SSL requests, and run a sniffer to see what's going on, I see the first request being handled perfectly, but already on the second request the client (MS-WAS) suddenly stops sending the proper SSL protocol in the middle of a session, so the server (Apache) hangs on read. There is no RST or anything else sent by the client indicating that it wanted to close this session... This could have been downplayed as a bug in MS-WAS or the Windows it runs on, if it weren't for the fact that as I said I also see a similar problem with Radview's Webload, and that both of these tools seem (at least as far as I heard) to be rather respected in the industry. So, has anyone else ever noticed such a problem? Can anyone perhaps shed some light on it? Thanks in advance, Nadav. -- Nadav Har'El| Sunday, Jan 20 2002, 7 Shevat 5762 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |Don't be irreplaceable. If you can't be http://nadav.harel.org.il |replaced, you can't be promoted.
Re: [PATCH] SSL_* in suexec safe env list
Hi,
I agree with Joshua completely that the conditioning on mod_ssl is not
necessary. However, comparing with the apache 1.3 version of suexec.c, and the
fact that in 2.0 ssl_engine_kernel.c (line 1035) still sets the SSI/CGI
environment variable HTTPS=on , I would recommand to have a triple rather then
double strncmp:
-if (!strncmp(*ep, "HTTP_", 5)) {
+if (!strncmp(*ep, "HTTP_", 5) || !strncmp(*ep, "HTTPS", 5) ||
+ !strncmp(*ep, "SSL_", 4)) {
On Sat, 2 Feb 2002, Joshua Slive wrote:
> I think this is the "right thing", but I won't commit it myself without a
> couple "+1"s, because I don't trust myself mucking with suexec. Someone
> suggested making this conditional on mod_ssl being included in the build,
> but I don't see the point. There doesn't seem to be any danger in allowing
> SSL_ to pass in all cases.
>
> Index: suexec.c
> ===
> RCS file: /home/cvs/httpd-2.0/support/suexec.c,v
> retrieving revision 1.17
> diff -u -d -b -r1.17 suexec.c
> --- suexec.c22 Nov 2001 07:42:13 - 1.17
> +++ suexec.c2 Feb 2002 22:40:14 -
> @@ -227,7 +227,7 @@
> cidx++;
>
> for (ep = environ; *ep && cidx < AP_ENVBUF-1; ep++) {
> -if (!strncmp(*ep, "HTTP_", 5)) {
> + if (!strncmp(*ep, "HTTP_", 5) || !strncmp(*ep, "SSL_", 4)) {
> cleanenv[cidx] = *ep;
> cidx++;
> }
>
--
Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics
tel:+972-54-227607 Technion - Israel Institute of Technology
fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL
"If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
Sunday, 22 Shevat 5762, 3 February 2002, 7:13PM
RE: SSI vs CGI
On Sun, 3 Feb 2002, Joshua Slive wrote:
>
> > From: Zvi Har'El [mailto:[EMAIL PROTECTED]]
> >
> > RedHat uses suexec by default, and this could be the reason. But I don't
> > really see why HTTPS=on is less safer then all the SSL_
> > variables. For me it is
> > a method to decide if my script should redirect to HTTP or HTTPS
> > URL's, and
> > there is no security breach in giving this script this piece of
> > information,
> > even thogh the script is run with suid set.
>
> There is no problem with the particular variable "HTTPS". The problem is
> with letting any arbitrary variable through, because suexec has no way to
> know for sure that the variable isn't dangerous. There is no problem with
> editting suexec.c to add your variables to the safe list.
>
> Joshua.
>
I looked at the sources of apache-1.3.23/src/support/suexec.c:
for (ep = environ; *ep && cidx < AP_ENVBUF-1; ep++) {
#ifdef MOD_SSL
if (!strncmp(*ep, "HTTP_", 5) ||
!strncmp(*ep, "HTTPS", 5) ||
!strncmp(*ep, "SSL_", 4)) {
#else
if (!strncmp(*ep, "HTTP_", 5)) {
#endif
cleanenv[cidx] = *ep;
cidx++;
}
This means this is exactly what I need. This is also OK for 1.3.22. However,
you need to compile suexec explicitly for MOD_SSL. So, there is no problem in
apache, only in redhat distribution: /usr/sbin/suexec comes with the apache
package, (currently apache-1.3.22-2), and it is not compiled with the MOD_SSL
flag, and the mod_ssl package (currently mod_ssl-2.8.5-1) is an add-on which
doesn't have its own /usr/sbin/suexec! I'll send a bug report to redhat. But,
To say the truth, I don't see why this compilation flag is needed at all.
Following the warning "DO NOT edit this code!!! Unless you know what you are
doing" I wouldn't change it myself, but can you see a reason why we cannot
always keep the HTTPS and SSL_ environment variables? Is this unsafe?
--
Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics
tel:+972-54-227607 Technion - Israel Institute of Technology
fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL
"If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
Sunday, 22 Shevat 5762, 3 February 2002, 6:54PM
RE: SSI vs CGI
On Sat, 2 Feb 2002, Joshua Slive wrote: > > > From: Zvi Har'El [mailto:[EMAIL PROTECTED]] > > > Friends, > > > > I compared the environment variables I get in an SSI, like > > , > > and a CGI, running a script like > > > > #!/usr/local/bin/zsh -x > > echo "Content-type: text/plain" > > echo > > printenv > > [missing env variables in cgi] > > Are you using suexec? (httpd -l will tell you) > > If so, you should be awary that suexec cleans the environment down to a > "safe" list of environment variables. Apache 2 should probably include the > SSL_* variables in that safe list, but it doesn't at the moment. > > Joshua. > RedHat uses suexec by default, and this could be the reason. But I don't really see why HTTPS=on is less safer then all the SSL_ variables. For me it is a method to decide if my script should redirect to HTTP or HTTPS URL's, and there is no security breach in giving this script this piece of information, even thogh the script is run with suid set. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Sunday, 21 Shevat 5762, 3 February 2002, 8:54AM
SSI vs CGI
Friends, I compared the environment variables I get in an SSI, like , and a CGI, running a script like #!/usr/local/bin/zsh -x echo "Content-type: text/plain" echo printenv In an HTTPS virtual host, there are many variables that are exported one method and not the other: More specifically, all the variables starting with SSL_ (e.g., SSL_CIPHER, SSL_SESSION_ID, etc.), are exported to the CGI script, but are not printed by the printenv SSI. This is in Apache/2.0.32-dev (Unix) mod_ssl/3.0a0 OpenSSL/0.9.6b (which I compiled from the latest CVS). I didn't notice an opposite problem in this version of Apache, but in another version - in the latest RedHat distro, which is Apache 1.3.22. I didn't see the problem in 1.3.23 in Solaris: The variable assignment HTTPS=on, which appears in a HTTPS virtual host in the output, is not exported to the CGI script! (The SSL_ variables are not exported in 1.3). I didn't try to install vanilla 1.3.23 on RedHat, ao I don't know what is the origin of the problem. If I have more specific info I'll post it. Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Saturday, 21 Shevat 5762, 2 February 2002, 11:37PM
AddLanguage
Hi Apache Developers, Comparing the AddLanguage directives in the default configuration for Apache 1.3.22 and the most recent CVS version of Apache 2.0, I noticed some differences. One, which is perhaps OK, is that the extension for Estonian files has been changed from .ee to .et, so now the extension matches the ISO-693-2 language code (although this is not stirctly necessary, as the Danish example shows). One which is *NOT OK*, is the omission of the line AddLanguage he .he which defines the extension for Hebrew files. I'll be very grateful if this lines is put back in. Thanks in advance, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Monday, 9 Shevat 5762, 21 January 2002, 6:00PM
Missing Mime Type: image/x-icon
Hi, Now that mozilla started supporting "favicons", I noticed that Apache's mime.types file doesn't have the type image/x-icon for .ico files. Thus, sites like yahoo or netscape, which use unknown and Netscape-Entreprise servers respectively, return the correct content type on the /favicon.ico URL, while others like apache or google, which use Apache and GWS servers respectively, return text/plain on this URL. Although this content type is not registered at IANA as far as I have been able to check, I do think it should be added to Apache's mime.types file. In the mean time, I added the line "AddType image/x-icon .ico" to my Apache server configuration file. Sincerely, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 Technion - Israel Institute of Technology fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Sunday, 7 Shevat 5762, 20 January 2002, 12:26PM
Re: [patch] Truncated port number in Via:
On Mon, 29 Oct 2001, Zvi Har'El wrote:
> In the latest CVS snapshot of apache2, proxy_http.c has a bug, in the function
> ap_proxy_http_determine_connection(), which, among other things, prepares the
> string server_portstr which is used in the Via header.
> prepares this string is
...
> This is a (tested) patch which does that:
>
To eliminate any douts, here is the patch as a unified CVS diff:
Index: proxy_http.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/proxy/proxy_http.c,v
retrieving revision 1.104
diff -u -r1.104 proxy_http.c
--- proxy_http.c2001/10/14 20:41:00 1.104
+++ proxy_http.c2001/10/29 13:22:18
@@ -194,7 +194,8 @@
char **url,
const char *proxyname,
apr_port_t proxyport,
-char *server_portstr) {
+char *server_portstr,
+ int server_portstr_size) {
int server_port;
apr_status_t err;
apr_sockaddr_t *uri_addr;
@@ -253,7 +254,7 @@
if (ap_is_default_port(server_port, r)) {
strcpy(server_portstr,"");
} else {
-apr_snprintf(server_portstr, sizeof(server_portstr), ":%d",
+apr_snprintf(server_portstr, server_portstr_size, ":%d",
server_port);
}
}
@@ -940,7 +941,8 @@
/* Step One: Determine Who To Connect To */
status = ap_proxy_http_determine_connection(p, r, p_conn, c, conf, uri,
&url, proxyname, proxyport,
-server_portstr);
+ server_portstr,
+ sizeof(server_portstr));
if ( status != OK ) {
return status;
}
--
Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics
tel:+972-54-227607 Technion - Israel Institute of Technology
fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL
"If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
Monday, 12 Heshvan 5762, 29 October 2001, 3:32PM
[patch] Truncated port number in Via:
Hi,
In the latest CVS snapshot of apache2, proxy_http.c has a bug, in the function
ap_proxy_http_determine_connection(), which, among other things, prepares the
string server_portstr which is used in the Via header. The line which
prepares this string is
apr_snprintf(server_portstr, sizeof(server_portstr), ":%d", server_port);
This could have been OK, if server_portstr was a character array. However,
server_portstr is a character pointer (it is a formal parameter of this
function), and there for its size is 4 (at least on a 32 bits machine), which
truncates the port number to the first two digits! E.g, if the port number is
8443, the result is ":84" (with a null byte). In the calling function,
ap_proxy_http_handler, server_portstr is really defined as a 32 bytes character
array, but this doesn't help here! It is easy to fix, of-course, e.g, by adding
another formal parameter for the size of the string, and fixing the call.
This is a (tested) patch which does that:
--- proxy_http.c~ Sun Oct 14 23:50:23 2001
+++ proxy_http.cMon Oct 29 15:17:12 2001
@@ -194,7 +194,8 @@
char **url,
const char *proxyname,
apr_port_t proxyport,
-char *server_portstr) {
+char *server_portstr,
+ int server_portstr_size) {
int server_port;
apr_status_t err;
apr_sockaddr_t *uri_addr;
@@ -253,7 +254,7 @@
if (ap_is_default_port(server_port, r)) {
strcpy(server_portstr,"");
} else {
-apr_snprintf(server_portstr, sizeof(server_portstr), ":%d",
+apr_snprintf(server_portstr, server_portstr_size, ":%d",
server_port);
}
}
@@ -940,7 +941,8 @@
/* Step One: Determine Who To Connect To */
status = ap_proxy_http_determine_connection(p, r, p_conn, c, conf, uri,
&url, proxyname, proxyport,
-server_portstr);
+ server_portstr,
+ sizeof(server_portstr));
if ( status != OK ) {
return status;
}
Best,
Zvi.
--
Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics
tel:+972-54-227607 Technion - Israel Institute of Technology
fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL
"If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
Monday, 12 Heshvan 5762, 29 October 2001, 3:00PM
