On 5/7/07, Jim Jagielski [EMAIL PROTECTED] wrote:
Seems to me that the more we work on the various 2.x trees
(2.0.x, 2.2.x and trunk), the harder it becomes to get
the various correct CHANGES entries in sync... For example,
the CHANGES for 2.2 and trunk just refer to changes up
to 2.0.56...
On 05/18/2007 02:23 AM, Justin Erenkrantz wrote:
On 5/17/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
why. Also the entity is not physically removed from the cache if it is
really stale.
This does not matter in the non HEAD case as it gets overwritten by
the fresh response,
but in the
Hello
I can compile Apache no problem. But when I try to debug (debug mode)
I get the error 'This application has failed to start because
libapr-1.dll was not found.
Then I see a DM0025: Error attaching to process messagebox.
Then unhandled exception in httpd.exe (NTDLL.DLL): 0xC135: DLL
Graham Dumpleton wrote:
The whole point of the changes which were made was to draw a well
defined line between the code modules used in the web application and
which reside in the document tree, or other specially specified areas
by way of mod_python module importer path, and the standard
Angus Comber wrote:
Hello
I can compile Apache no problem. But when I try to debug (debug mode)
I get the error 'This application has failed to start because
libapr-1.dll was not found.
Then I see a DM0025: Error attaching to process messagebox.
Then unhandled exception in httpd.exe
On 5/18/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
Well, because rv == !OK, wouldn't the CACHE_REMOVE_URL filter hit?
That should do the dirty deed, no? -- justin
No, as the CACHE_REMOVE_URL filter will only work if there is a
cache-handle or a cache-stale_handle. We have neither, as
On 05/18/2007 11:26 PM, Justin Erenkrantz wrote:
On 5/18/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
Well, because rv == !OK, wouldn't the CACHE_REMOVE_URL filter hit?
That should do the dirty deed, no? -- justin
No, as the CACHE_REMOVE_URL filter will only work if there is a
On 5/18/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
@@ -477,8 +477,10 @@
reason = No Last-Modified, Etag, or Expires headers;
}
else if (r-header_only) {
-/* HEAD requests */
-reason = HTTP HEAD request;
+/* Forbid HEAD requests unless we have it
On 5/17/07, Niklas Edmundsson [EMAIL PROTECTED] wrote:
Has there been any progress on PR41230? I submitted a patch that at
least seems to improve the situation that now seems to have seen some
testing by others as well.
As I have stated before, it would be really nice if a fix for this
could
On 04/16/2007 10:58 PM, Ruediger Pluem wrote:
Looking at the problem I noticed a related problem already mentioned in a
FIXME comment:
It can happen that the headers of a 304 response from the backend cause the
response to be
uncacheable (e.g. Cache-Control: no-store).
Currently this
Jorey Bump writes:
Graham Dumpleton wrote:
The whole point of the changes which were made was to draw a well
defined line between the code modules used in the web application and
which reside in the document tree, or other specially specified areas
by way of mod_python module importer
11 matches
Mail list logo
