Re: mod_cache caching the 301 Moved Permanently
On Thu, Jul 07, 2005 at 09:22:25PM +0200, [EMAIL PROTECTED] wrote: > Have you checked > http://mail-archives.apache.org/mod_mbox/httpd-dev/200504.mbox/[EMAIL > PROTECTED] ? > > It contains a small patch which was not discussed any further here. Hi, i tried your patch today. Unfortunately cache->handle->cache_obj->info.status isn't set during cache_out_filter(), but cache->handle->status is. (It gets set in mod_disk_cache.c:499 during recall_headers().) I tried to use that and it seems to work. However, not knowing much of how the whole thing fits together, i do not claim that this is the solution. An updated version of your patch below. Thanks && Regards Hansjoerg --- mod_cache.c.orig2005-04-11 17:47:03.0 +0200 +++ mod_cache.c 2005-07-11 16:52:35.913264943 +0200 @@ -219,7 +219,10 @@ ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS, r->server, "cache: running CACHE_OUT filter"); - + +/* restore status of cached response */ +r->status = cache->handle->status; + /* recall_headers() was called in cache_select_url() */ cache->provider->recall_body(cache->handle, r->pool, bb); -- IT ServicesUniversity of Innsbruck CFB4 D6E7 33F4 34C0 18B9 6661 E355 4337 3F8B D9C2 http://purl.org/net/hansjoerg.pehofer/public_key signature.asc Description: Digital signature
Re: mod_mbox user interface
On Jul 11, 2005, at 9:06 PM, Maxime Petazzoni wrote: As promised : a first try at XHTML mockup. Comments about DOM structure and XHTML semantics are welcome ! http://skikda.bulix.org/~sam/ajax/jsless/ 2005 | It looks great except for all the wasted whitespace. Jul | One thing I look for in a mail interface is to be narrow Jun | enough so that the window can be displayed side-by-side May | with a terminal window for cut-n-paste. You could fix Apr | that by changing the wide mbox list to a simple one Mar | limited to four characters, like the one on the left. Feb | Jan | And you can place the number of messages per month in | a roll-over title instead of a table. 2004 | Dec | Nov | Oct | ... | What do you think? Roy
Re: mod_mbox user interface
Maxime Petazzoni wrote:. As promised : a first try at XHTML mockup. Comments about DOM structure and XHTML semantics are welcome ! http://skikda.bulix.org/~sam/ajax/jsless/ On firefox/win32, the "box list" and "message lists" aren't vertically aligned correctly (at least for me.) Other than that, it's quite pretty. You could reduce the whitespace margins considerably, maybe even lose the box around the year/month listings on the side. From a usability perspective, I like 'three-pane' sorts of interfaces, but I'm often infuriated by things that waste a lot of space so I can't read the actual message. The huge space allocated to the logo at the top could be reduced (that will probably be easy to template away, but if you set a bad example for people, they'll follow it -- also I get the feeling that the message list takes up space that I could use to read the message...
Re: [PATCH] add our version to string to httpd banner
"Philip M. Gollucci" <[EMAIL PROTECTED]> writes:
> module/apache/command.c
> ===
> --- module/apache/command.c (revision 210049)
> +++ module/apache/command.c (working copy)
> @@ -18,6 +18,7 @@
>
> #include "apreq_util.h"
> #include "apreq_module_apache.h"
> +#include "apreq_version.h"
>
> #include "httpd.h"
> #include "http_log.h"
> @@ -152,6 +153,7 @@
> apr_initialize();
> apr_pool_create(&p, NULL);
> apreq_initialize(p);
> +ap_add_version_component(p, apr_psprintf(p, "mod_apreq/%s",
> APREQ_VERSION_STRING));
Line wrap.
> ap_register_cleanup(sp, p, apreq_cleanup, apreq_cleanup);
> }
>
> Index: module/apache2/filter.c
> ===
> --- module/apache2/filter.c (revision 210049)
> +++ module/apache2/filter.c (working copy)
> @@ -29,6 +29,7 @@
> #include "apreq_private_apache2.h"
> #include "apreq_error.h"
> #include "apreq_util.h"
> +#include "apreq_version.h"
>
> static void *apreq_create_dir_config(apr_pool_t *p, char *d)
> {
> @@ -423,6 +424,8 @@
> {
> apr_status_t status;
>
> +ap_add_version_component(p, apr_psprintf(p, "mod_apreq/%s",
> APREQ_VERSION_STRING));
Line wrap.
--
Joe Schaefer
Re: mod-cache-requestor plan
On 7/11/05 11:48 PM, "Parin Shah" <[EMAIL PROTECTED]> wrote: should be > refreshed. but, if we consider keeping non-popular but expensive pages in > the cache, in that case houw would te mod-c-requester would make the > decision? > We have been down this road. The way one might solve it is to allow mod_cache to be able to reload an object while serving the "old" one. Example: cache /A for 600 seconds after 500 seconds, request /A with special header (or from special client, etc) and cache does not serve from cache, but rather pretends the cache has expired. do normal refresh stuff. The cache will continue to server /A even though it is refreshing it Make any sense? This way, a simple cron job can be used to refresh desired objects. Also, one of the flaws of mod_disk_cache (at least the version I am looking at) is that it deletes objects before reloading them. It is better for many reasons to only replace them. That's the best way to accomplish what I described above. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: mod_cache caching the 301 Moved Permanently
Hansjoerg Pehofer wrote: > On Thu, Jul 07, 2005 at 09:22:25PM +0200, [EMAIL PROTECTED] wrote: > >>Have you checked >>http://mail-archives.apache.org/mod_mbox/httpd-dev/200504.mbox/[EMAIL >>PROTECTED] ? >> >>It contains a small patch which was not discussed any further here. > > > Hi, > > i tried your patch today. Unfortunately > cache->handle->cache_obj->info.status isn't set during cache_out_filter(), > but cache->handle->status is. > (It gets set in mod_disk_cache.c:499 during recall_headers().) Many thanks for the feedback and the corrected patch. I checked my patch again and must admit that it does only make sense on Apache 2.1. For Apache 2.0.x your patch is the correct one. Question to the mod_cache gurus: While mod_mem_cache restores the status during recall_headers in Apache 2.0.54 it seems that mod_mem_cache does not do this in Apache 2.1.x (Maybe fixed meanwhile my latest revision of mod_mem_cache.c is 178625 and viewcvs is currently down), whereas mod_disk_cache still does this in Apache 2.1.x in file_cache_recall_mydata which is called by open_entity. Is this behaviour intended? Regards Rüdiger [..cut..]
Re: mod_cache caching the 301 Moved Permanently
[EMAIL PROTECTED] wrote: Hansjoerg Pehofer wrote: On Thu, Jul 07, 2005 at 09:22:25PM +0200, [EMAIL PROTECTED] wrote: Have you checked http://mail-archives.apache.org/mod_mbox/httpd-dev/200504.mbox/[EMAIL PROTECTED] ? It contains a small patch which was not discussed any further here. Hi, i tried your patch today. Unfortunately cache->handle->cache_obj->info.status isn't set during cache_out_filter(), but cache->handle->status is. (It gets set in mod_disk_cache.c:499 during recall_headers().) Many thanks for the feedback and the corrected patch. I checked my patch again and must admit that it does only make sense on Apache 2.1. For Apache 2.0.x your patch is the correct one. Question to the mod_cache gurus: While mod_mem_cache restores the status during recall_headers in Apache 2.0.54 it seems that mod_mem_cache does not do this in Apache 2.1.x (Maybe fixed meanwhile my latest revision of mod_mem_cache.c is 178625 and viewcvs is currently down), whereas mod_disk_cache still does this in Apache 2.1.x in file_cache_recall_mydata which is called by open_entity. Is this behaviour intended? 2.0 is quite a bit behind when it comes to mod_cache. mod_mem_cache has gotten a lot less attention in 2.1 as mod_disk_cache has. That said, in 2.1, I think we should restore status in mod_cache, not in the cache providers. Ofcourse, if that isn't possible for whatever reason, the restoration has to be done in _all_ cache providers. The above might explain the discrepancies... Sander
Re: mod_cache caching the 301 Moved Permanently
Sander Striker wrote: > [EMAIL PROTECTED] wrote: [..cut..] >> Question to the mod_cache gurus: >> While mod_mem_cache restores the status during recall_headers in >> Apache 2.0.54 >> it seems that mod_mem_cache does not do this in Apache 2.1.x (Maybe >> fixed meanwhile >> my latest revision of mod_mem_cache.c is 178625 and viewcvs is >> currently down), whereas >> mod_disk_cache still does this in Apache 2.1.x in >> file_cache_recall_mydata which is >> called by open_entity. Is this behaviour intended? > > > 2.0 is quite a bit behind when it comes to mod_cache. mod_mem_cache has > gotten > a lot less attention in 2.1 as mod_disk_cache has. > > That said, in 2.1, I think we should restore status in mod_cache, not in > the cache Sorry for being confused. But maybe my question was not completely correct. mod_disk_cache does not restore r->status directly but it restores the status information to cache->handle->cache_obj->info.status. This gives mod_cache the opportunity to restore r->status from this (as my patch does). The problem is that mod_mem_cache does not seem to restore the status information at all from its storage. This way mod_cache has no chance to restore it in this case. I agree with you that mod_cache should set r->status with the information restored by the provider to cache->handle->cache_obj->info.status. mod_cache should take the final decision if it does that or not. This decision should not be done by the providers. > providers. Ofcourse, if that isn't possible for whatever reason, the > restoration > has to be done in _all_ cache providers. The above might explain the > discrepancies... But all cache providers have to store it in their storage and have to restore it from there to the caching data structure. Maybe this is what you wanted to say? Regards Rüdiger
Re: mod_cache caching the 301 Moved Permanently
[EMAIL PROTECTED] wrote: Sander Striker wrote: [...] That said, in 2.1, I think we should restore status in mod_cache, not in the cache Sorry for being confused. But maybe my question was not completely correct. It was fine; I'm being 'lazy' and not looking at the code, but going by memory instead. Sometimes I forget pieces... mod_disk_cache does not restore r->status directly but it restores the status information to cache->handle->cache_obj->info.status. This gives mod_cache the opportunity to restore r->status from this (as my patch does). The problem is that mod_mem_cache does not seem to restore the status information at all from its storage. Right, this is where mod_disk_cache did get some attention and mod_mem_cache didn't yet. This way mod_cache has no chance to restore it in this case. I agree with you that mod_cache should set r->status with the information restored by the provider to cache->handle->cache_obj->info.status. mod_cache should take the final decision if it does that or not. This decision should not be done by the providers. Indeed. [...] providers. Ofcourse, if that isn't possible for whatever reason, the restoration has to be done in _all_ cache providers. The above might explain the discrepancies... But all cache providers have to store it in their storage and have to restore it from there to the caching data structure. Maybe this is what you wanted to say? Yup. Sander
ErrorDocument 'OK' behavior
The core and mod_cgi generate documents with the 'default' response code - 200 OK is set before the handler is ever invoked, or a non-200 code if they are handling an error. This isn't true of some other modules, including mod_jk. It's also not true of mod_cgi if the 'Status: 200' field is passed to httpd. In those cases, the "error" page returned is a 200 OK, which is clearly wrong. I was about to blame the design of mod_jk, however is there any reason we shouldn't ensure this behavior, for httpd-2.1, in the core http output filter? I'll craft and commit such a patch after the next 1.3/2.0 releases, unless I anyone voices objections to re-overriding the status, status_line values to their original error values. Bill
Re: ErrorDocument 'OK' behavior
William A. Rowe, Jr. wrote: The core and mod_cgi generate documents with the 'default' response code - 200 OK is set before the handler is ever invoked, or a non-200 code if they are handling an error. This isn't true of some other modules, including mod_jk. It's also not true of mod_cgi if the 'Status: 200' field is passed to httpd. In those cases, the "error" page returned is a 200 OK, which is clearly wrong. I was about to blame the design of mod_jk, however is there any reason we shouldn't ensure this behavior, for httpd-2.1, in the core http output filter? I'll craft and commit such a patch after the next 1.3/2.0 releases, unless I anyone voices objections to re-overriding the status, status_line values to their original error values. I'm not sure that I understand your message. But people do use mod_cgi to deliberatly change status codes on ErrorDocuments. For example, and ErrorDocument 404 pointed at a CGI can be used to generate dynamic content only for URLs that don't map to filesystem objects. Joshua.
Re: mod-cache-requestor plan
> We have been down this road. The way one might solve it is to allow > mod_cache to be able to reload an object while serving the "old" one. > > Example: > > cache /A for 600 seconds > > after 500 seconds, request /A with special header (or from special client, > etc) and cache does not serve from cache, but rather pretends the cache has > expired. do normal refresh stuff. > > The cache will continue to server /A even though it is refreshing it > As Graham suggested, such mechanism will not refresh the pages those are non-popular but expensive to load. which could incur lot of overhead. But, other than that, This looks really good solution. > > Also, one of the flaws of mod_disk_cache (at least the version I am looking > at) is that it deletes objects before reloading them. It is better for many > reasons to only replace them. That's the best way to accomplish what I > described above. If we implement it the way you suggested, then this problem would automatically be solved. -Parin.
Re: ErrorDocument 'OK' behavior
At 08:57 PM 7/12/2005, Joshua Slive wrote: >William A. Rowe, Jr. wrote: >>The core and mod_cgi generate documents with the 'default' >>response code - 200 OK is set before the handler is ever >>invoked, or a non-200 code if they are handling an error. >>This isn't true of some other modules, including mod_jk. >>It's also not true of mod_cgi if the 'Status: 200' field >>is passed to httpd. In those cases, the "error" page returned >>is a 200 OK, which is clearly wrong. >>I was about to blame the design of mod_jk, however is there >>any reason we shouldn't ensure this behavior, for httpd-2.1, >>in the core http output filter? >>I'll craft and commit such a patch after the next 1.3/2.0 >>releases, unless I anyone voices objections to re-overriding >>the status, status_line values to their original error values. > >I'm not sure that I understand your message. But people do use mod_cgi to >deliberatly change status codes on ErrorDocuments. For example, and >ErrorDocument 404 pointed at a CGI can be used to generate dynamic content >only for URLs that don't map to filesystem objects. Hmmm. For the purposes of httpd-2.2 (I'm not asking about any backporting to change expected behavior in 1.3/2.0) ... ... is this really the right mechanism? Perhaps an additional arg to ErrorDocument to set an explicit reaction? E.g. turning a 404 into a 302, or providing a 'good' page 200 in place of a missing page. Or a generic arg which says respect the errordocument's result code? The side effects of such a handler are obviously dangerous for web crawlers, since missing pages (in this example) might never be struck from a given index or collection. I can see how what you've described is incredibly useful, but also note that simple content, e.g. replacing the stock error text with a more informative .jsp page becomes very difficult; the mod_jk + tomcat jsp engine always sets r->status to 200. Bill
Re: mod_mbox user interface
Re- > Let's go :) A "pre-alpha ultra-experimental" version is available at my development server : http://skikda.bulix.org/archives/dev/ This version includes the XHTML mbox list output, a Javascript-less browsing interface and a stub for the AJAX browser interface. If your browser does not support Javascript, the link to the AJAX browser won't even be displayed. Browser features only includes mailbox thread listing (no re-sorting), opening a mail (the message list collapse into a context viewer), and closing the mail window. In both modes, the box list is missing. It will be added soon. This is my first wide Javascript DOM alteration functions, and I'm not sure I'm doing things well or optimized enough. As usual, comments, reviews and ideas are welcome ! - Sam (going to bed as the sun rises, one more time ...) -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
