You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 2003/05/13 20:23:55 UTC
fix for ExpiresByType, including dynamic content
the attached patch (against 2.0) defers handling of the ExpiresByType
settings to an output filter, so it should correctly add the fields
to a cgi script in the scope of the directive.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: fix for ExpiresByType, including dynamic content
Posted by Bill Stoddard <bi...@wstoddard.com>.
Rodent of Unusual Size wrote:
>Bill Stoddard wrote:
>
>
>>I am still reviewing the patch but it does need some minor tweaking to
>>remove unused variables.
>>
>>
>
>whoops. artifact of code motion. updated patch attached.
>
>
Looks good.
+1 for 2.1 and backporting into 2.0.
Bill
Global pool and shared memory for modules
Posted by "Imran S. Patel" <im...@cs.ucsb.edu>.
Hi all,
I am writing an Apache 2 module and so far things have been progressing
very nicely, thanks to the nice API and the wonderfully designed APR
libraries. However, I was tripped up by the usage of global data
structures in my module. The problem that I later discovered was that
merely making variables global or allocating stuff from the pconf pool
doesn't make things "module-wide" global. So my question is:
How do I share a global hash-table or a counter or anything across all
instances of my module in a portable manner?
Also, I looked at the shared memory facility provided by APR. But even if
I use shared memory, from which pool do I allocate the apr_shm_t structure
and how do i destroy the shared memory in a safe manner later on?
Is there any documentation/"simple" module which does this or explain
apache module behavior under different MPMs?
Lots of questions, i guess! :)
TIA
imran
-------------------------------------------------------------------------------
A witty saying proves nothing.
-- Voltaire
Re: fix for ExpiresByType, including dynamic content
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Bill Stoddard wrote:
> I am still reviewing the patch but it does need some minor tweaking to
> remove unused variables.
whoops. artifact of code motion. updated patch attached.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: fix for ExpiresByType, including dynamic content
Posted by Bill Stoddard <bi...@wstoddard.com>.
I am still reviewing the patch but it does need some minor tweaking to
remove unused variables.
Compiling...
mod_expires.c
C:\home\apache\apache20\clean\httpd-2.0\modules\metadata\mod_expires.c(545)
: warning C4101: 'additional' : unreferenced local variable
C:\home\apache\apache20\clean\httpd-2.0\modules\metadata\mod_expires.c(547)
: warning C4101: 'additional_sec' : unreferenced local variable
C:\home\apache\apache20\clean\httpd-2.0\modules\metadata\mod_expires.c(546)
: warning C4101: 'expires' : unreferenced local variable
C:\home\apache\apache20\clean\httpd-2.0\modules\metadata\mod_expires.c(548)
: warning C4101: 'timestr' : unreferenced local variable
C:\home\apache\apache20\clean\httpd-2.0\modules\metadata\mod_expires.c(544)
: warning C4101: 'base' : unreferenced local variable
Rodent of Unusual Size wrote:
>the attached patch (against 2.0) defers handling of the ExpiresByType
>settings to an output filter, so it should correctly add the fields
>to a cgi script in the scope of the directive.
>
>
Bill
Re: fix for ExpiresByType, including dynamic content
Posted by André Malo <nd...@perlig.de>.
* Greg Ames wrote:
> André Malo wrote:
>> * Rodent of Unusual Size wrote:
>>
>>
>>>the attached patch (against 2.0) defers handling of the ExpiresByType
>>>settings to an output filter, so it should correctly add the fields
>>>to a cgi script in the scope of the directive.
>>
>>
>> There's an accompanying feature request in the bug db
>> (<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7991>)
>>
>> Can we partially follow this request and combine your filter with
>> AddOutputFilterByType?
>
> IMO the two should be separate. The Rodent's patch should take care of a
> problem that's been around for ages. For example, in 1.3 ExpiresByType won't
> work as you might expect if a CGI or other handler sets the type to something
> different than the default type. Fortunately 2.0 gives us a clean way to defer
> this decision until the last possible moment. We shouldn't confuse the issue by
> introducing new/changed externals at the same time.
Ok, but AddoutputFilterByType semantics are already there. We should really
consider to use ap_add_output_filters_by_type at least (at first?)
internally instead of baking the next redundant (?) piece of code and may
extend the UI later (Though I don't see the point why not making the type
argument in ExpiresByType optional and document the EXPIRATION filter - now
or in 2.1, similar to the server-parsed handler trick).
nd
--
> [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet?
DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da
so reinpacken und dann absolut positionieren ...
-- Florian Hartig und Lars Kasper in dciwam
Re: fix for ExpiresByType, including dynamic content
Posted by Greg Ames <gr...@apache.org>.
André Malo wrote:
> * Rodent of Unusual Size wrote:
>
>
>>the attached patch (against 2.0) defers handling of the ExpiresByType
>>settings to an output filter, so it should correctly add the fields
>>to a cgi script in the scope of the directive.
>
>
> There's an accompanying feature request in the bug db
> (<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7991>)
>
> Can we partially follow this request and combine your filter with
> AddOutputFilterByType?
IMO the two should be separate. The Rodent's patch should take care of a
problem that's been around for ages. For example, in 1.3 ExpiresByType won't
work as you might expect if a CGI or other handler sets the type to something
different than the default type. Fortunately 2.0 gives us a clean way to defer
this decision until the last possible moment. We shouldn't confuse the issue by
introducing new/changed externals at the same time.
Greg
Re: fix for ExpiresByType, including dynamic content
Posted by André Malo <nd...@perlig.de>.
* Rodent of Unusual Size wrote:
> the attached patch (against 2.0) defers handling of the ExpiresByType
> settings to an output filter, so it should correctly add the fields
> to a cgi script in the scope of the directive.
There's an accompanying feature request in the bug db
(<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7991>)
Can we partially follow this request and combine your filter with
AddOutputFilterByType? e.g., a slight semantic change (keeping
backwards-compat), so that you have two choices, either:
ExpiresByType "access plus 1 month"
AddoutputFilterByType EXPIRATION image/gif image/jpeg image/png
or:
ExpiresByType image/gif "access plus 1 month"
#etc.
+1 on concept anyway (just had only a short look over the patch).
nd
--
"Die Untergeschosse der Sempergalerie bleiben währenddessen aus
statistischen Gründen geflutet." -- Spiegel Online