You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 2002/10/03 00:20:50 UTC
Re: cvs commit: httpd-2.0/server core.c util_script.c
On 2 Oct 2002 wrowe@apache.org wrote:
> Index: util_script.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/server/util_script.c,v
> retrieving revision 1.79
> retrieving revision 1.80
> diff -u -r1.79 -r1.80
> --- util_script.c 23 Jun 2002 06:15:03 -0000 1.79
> +++ util_script.c 2 Oct 2002 21:35:57 -0000 1.80
> @@ -266,7 +266,8 @@
>
> apr_table_addn(e, "SERVER_SIGNATURE", ap_psignature("", r));
> apr_table_addn(e, "SERVER_SOFTWARE", ap_get_server_version());
> - apr_table_addn(e, "SERVER_NAME", ap_get_server_name(r));
> + apr_table_addn(e, "SERVER_NAME",
> + ap_escape_html(r->pool, ap_get_server_name(r)));
> apr_table_addn(e, "SERVER_ADDR", r->connection->local_ip); /* Apache */
> apr_table_addn(e, "SERVER_PORT",
> apr_psprintf(r->pool, "%u", ap_get_server_port(r)));
>
Lets not encode env variables, as we discussed earlier.
Escaping them is bogus and doesn't solve anything since there are all
sorts of variables that aren't and shouldn't be encoded.
Re: cvs commit: httpd-2.0/server core.c util_script.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
If someone reverts that -part- of the commit, and changes CHANGES
to reflect this group decision, I will bring in that commit tomorrow a.m.
before the final tag and roll.
Sorry if I wasn't clear on the consensus decision. +1.
Bill
At 05:54 PM 10/2/2002, Joshua Slive wrote:
>On Wed, 2 Oct 2002, Marc Slemko wrote:
>> Lets not encode env variables, as we discussed earlier.
>>
>> Escaping them is bogus and doesn't solve anything since there are all
>> sorts of variables that aren't and shouldn't be encoded.
>
>+1 to what Marc says. The encoding serves no purpose. Preventing the
>sample cgi scripts from being included in a "make install" would be a
>great idea.
>
>Joshua.
Re: Mod_cache and multiple brigade problem.
Posted by "Paul J. Reder" <re...@remulak.net>.
It looks to me like you and I are on the same path. I'm currently
fixing a problem related to freshness computations, but I'm also
looking in to why it seems to fetch files more than it needs to.
I'll let you know if I find anything. Please keep me posted.
Thanks,
Paul J. Reder
Matthieu Estrade wrote:
> Hi,
>
> I worked more on debug in mod_cache.
> what i found is:
>
> when the bug is happening, and it's not all the time:
>
> the request are served from cache 1/2 times
> so: first request is cached, the second one served from the cache, the
> third one is cached.
>
> find_entry function in cache_hash is unable to find the entry in the
> hash table.
> the function find it 1/2 times.
>
> i controled the modulo and the hash, they seems to be ok
> the pointer to the array of hash is always at the beginning when it
> start the check,
> but 1/2 times it find the hash....
>
> i can't find what is modifying the array of hash and why he is unable to
> find it
>
> something which is maybe interesting, is the problem appear when i put
> only one object in the cache...
>
> i will continue tomorow to search,
>
> regards,
>
> Estrade Matthieu
>
>
>
>
>
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Mod_cache and multiple brigade problem.
Posted by Matthieu Estrade <me...@axiliance.com>.
Hi,
I worked more on debug in mod_cache.
what i found is:
when the bug is happening, and it's not all the time:
the request are served from cache 1/2 times
so: first request is cached, the second one served from the cache, the
third one is cached.
find_entry function in cache_hash is unable to find the entry in the
hash table.
the function find it 1/2 times.
i controled the modulo and the hash, they seems to be ok
the pointer to the array of hash is always at the beginning when it
start the check,
but 1/2 times it find the hash....
i can't find what is modifying the array of hash and why he is unable to
find it
something which is maybe interesting, is the problem appear when i put
only one object in the cache...
i will continue tomorow to search,
regards,
Estrade Matthieu
Re: Mod_cache and multiple brigade problem.
Posted by "Paul J. Reder" <re...@remulak.net>.
I'm looking at some odd behavior in the cache code right now related to
cache expiration processing. I might get to looking at this problem before
this weekend. I'll post any info I find in order to help you fix it this
weekend if I don't finish it before then...
Brian Pane wrote:
> Estrade Matthieu wrote:
>
>> Hi,
>>
>> I found problems in mod_cache + mod_proxy and handling multiple brigade.
>> If someone have ideas on it...
>>
>> 1)
>> When the mod_cache is trying to cache a document in multiple brigade,
>> it store and concat each brigade in cache->saved_brigade.
>> When the first brigade is cached, the r->headers_out are all
>> available, but when the others brigade are going throught the
>> mod_cache, there is no more r->headers_out.
>
>
>
> I'll take a look at this as soon as I have time (probably this Saturday).
>
> Brian
>
>
>
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Mod_cache and multiple brigade problem.
Posted by Brian Pane <br...@apache.org>.
Estrade Matthieu wrote:
> Hi,
>
> I found problems in mod_cache + mod_proxy and handling multiple brigade.
> If someone have ideas on it...
>
> 1)
> When the mod_cache is trying to cache a document in multiple brigade,
> it store and concat each brigade in cache->saved_brigade.
> When the first brigade is cached, the r->headers_out are all
> available, but when the others brigade are going throught the
> mod_cache, there is no more r->headers_out.
I'll take a look at this as soon as I have time (probably this Saturday).
Brian
Mod_cache and multiple brigade problem.
Posted by Estrade Matthieu <es...@ifrance.com>.
Hi,
I found problems in mod_cache + mod_proxy and handling multiple brigade.
If someone have ideas on it...
1)
When the mod_cache is trying to cache a document in multiple brigade, it
store and concat each brigade in cache->saved_brigade.
When the first brigade is cached, the r->headers_out are all available,
but when the others brigade are going throught the mod_cache, there is
no more r->headers_out.
Mod_cache is writting the headers informations when it find the last
brigade (containing EOS bucket).
So at this moment, mod_cache is able to store headers he put in "info",
but not the others one he should find in r->headers_out
So i can read the Server header of my reverse proxy instead of the
backend headers.
This bug happen really random and i am not able at the moment to exactly
find why ?
2)
When a document in multiple brigade is handled by reverse proxy and cache.
The first time, it cache the document without error. (the browser
display the document)
The second time, it serve the document from cache.( the browser doesn't
display the document)
When the browser receive the document from cache, it's impossible for
him to display it but he received the good data ( i do a md5sum to
control ).
The only difference between the two answer, is the not cached and first
request doesn't contain a content-length
the second request receiving data from cache contain differents headers
like content-length (seems to be right) and some more headers like Age.
3)
When a document is cached the first time, the debug message say that he
will cache the url.
I put debug in the cache_write_entity_headers and body to see if they
all finish well.
the debug message never display an error on that, but the next request
which should be handled by cache is still handled by the reverse proxy
and the cache say again he will cache the url...
In conclusion, do you think all these problems could be linked ?
What is amazing is i do my test on two different boxes:
the mod_cache + mod_proxy is working fine on redhat 8, a document of
1200bytes is handled in one brigade
the mod_cache + mod_proxy is not working properly on a redhat 7.2 and
the same document as above is handled in 2 brigade...
The compilations lines and the source code are EXACTLY the same.
The backend server is the same too for all the test.
I will try to find more details about this problems.
regards,
Estrade Matthieu
______________________________________________________________________
Etudiant: Wanadoo t'offre le Pack eXtense Haut D�bit soit 150,92 euros
d'�conomies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant
Re: cvs commit: httpd-2.0/server core.c util_script.c
Posted by André Malo <nd...@perlig.de>.
* Joe Orton wrote:
> If this change does get reverted so that SERVER_NAME is not encoded
> internally again, the error includes need updating so that is is
> encoded there instead:
>
> --- error/include/bottom.html~ 2002-07-11 20:07:03.000000000 +0100
>+++ error/include/bottom.html 2002-10-09 12:04:59.000000000 +0100
> @@ -6,7 +6,7 @@
> <dl>
> <dd>
> <address>
> - <a href="/"><!--#echo encoding="none" var="SERVER_NAME" --></a>
> + <a href="/"><!--#echo encoding="url" var="SERVER_NAME" --></a>
should be encoding="entity". "url" is not right here.
nd
--
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;
# André Malo # http://www.perlig.de #
Re: cvs commit: httpd-2.0/server core.c util_script.c
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Oct 02, 2002 at 03:54:18PM -0700, Joshua Slive wrote:
>
> On Wed, 2 Oct 2002, Marc Slemko wrote:
> > Lets not encode env variables, as we discussed earlier.
> >
> > Escaping them is bogus and doesn't solve anything since there are all
> > sorts of variables that aren't and shouldn't be encoded.
>
> +1 to what Marc says. The encoding serves no purpose. Preventing the
> sample cgi scripts from being included in a "make install" would be a
> great idea.
If this change does get reverted so that SERVER_NAME is not encoded
internally again, the error includes need updating so that is is encoded
there instead:
--- error/include/bottom.html~ 2002-07-11 20:07:03.000000000 +0100
+++ error/include/bottom.html 2002-10-09 12:04:59.000000000 +0100
@@ -6,7 +6,7 @@
<dl>
<dd>
<address>
- <a href="/"><!--#echo encoding="none" var="SERVER_NAME" --></a>
+ <a href="/"><!--#echo encoding="url" var="SERVER_NAME" --></a>
<br />
<!--#config timefmt="%c" -->
<small><!--#echo encoding="none" var="DATE_LOCAL" --></small>
Re: cvs commit: httpd-2.0/server core.c util_script.c
Posted by Joshua Slive <jo...@slive.ca>.
On Wed, 2 Oct 2002, Marc Slemko wrote:
> Lets not encode env variables, as we discussed earlier.
>
> Escaping them is bogus and doesn't solve anything since there are all
> sorts of variables that aren't and shouldn't be encoded.
+1 to what Marc says. The encoding serves no purpose. Preventing the
sample cgi scripts from being included in a "make install" would be a
great idea.
Joshua.