RE: URI decoding problem

Sorry for typo: .replaceAll("\\+","%2B") >I use java.lang.String(...).replaceAll("+","%2B") before >forwarding request to another pipeline...

RE: URI decoding problem

limetschek [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 4:08 AM To: dev@cocoon.apache.org Subject: Re: URI decoding problem Fuad Efendi schrieb: > API Docs are probably with typo: > * <map:generate > src="http://remote/page?param1={url-encode:{request-param:param1

RE: URI decoding problem

API Docs are probably with typo: * ; public final class URLDecodeModule extends AbstractInputModule implements ThreadSafe { {url-decode:...}? instead of url-encode?

RE: URI decoding problem

I found link http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/modules/in put/URLDecodeModule.html Thanks -Original Message- From: Fuad Efendi I can't understand why Cocoon/Tomcat cand't properly decode such URLs: .../CD%20%2B%20DVD%20Drives/ URL: CD +

URI decoding problem

I can't understand why Cocoon/Tomcat cand't properly decode such URLs: .../CD%20%2B%20DVD%20Drives/ URL: CD + DVD Drives Encode-for-uri: CD%20%2B%20DVD%20Drives

RE: Not caching pages with continuations (was:...where is 304?)

Continuation is designed specifically to make User-Form interaction unique, it is IMPOSSIBLE to cache it. URL contains unique continuation Id, we are using GET method, and we are submitting new continuation Id (via hidden field). Response will be unique (not-cached yet), even if we are using httpd

RE: FW: HTTPD mod_cache HttpCacheAction: where is 304?

I don't understand what is a problem. If we need to cache smth, we need clearly GET method without any cookies. Continuation must be a part of URL to be cached. But it does not make a sence, because new request from the same and/or from different user will request URL with different (not-cached yet

RE: FW: HTTPD mod_cache HttpCacheAction: where is 304?

Ard Schrijvers wrote: > > is there any best practice to have cforms in urls you do not know on > beforehand, with continuations? > Continuation is just randomly generated token, unique to each user interaction (like as session Id). Even if it is cached, even if GET is used as a form method, ne

RE: FW: HTTPD mod_cache HttpCacheAction: where is 304?

Server is slightly overloaded (80% CPU average, Robot is crawling Internet, addind >5 of new products daily), but HTTPD works fine... www.tokenizer.org please do not reload it;) I'll check it from behind-corporate-proxy today. Also I need to test that cache is not shared (still...) between work

RE: FW: HTTPD mod_cache HttpCacheAction: where is 304?

acheAction: where is 304? On 1/28/07, Fuad Efendi <[EMAIL PROTECTED]> wrote: > Following to > http://wiki.apache.org/cocoon/ControllingModCache > > I found this class: org.apache.cocoon.acting.HttpCacheAction (dated > 2004-07-29) > > Unfortunately, this action can&#x

RE: Not caching pages with continuations (was:...where is 304?)

Hi, I created simple class (additionally to existing HttpCacheAction. I am using also simple JavaScript which generates 304 (don't know Cocoon in-depth yet...) The rest: HTTPD uses _few_ multithreaded processes (worker model), and few per-process instances of cache (It was true with v.2.0.44, I

FW: HTTPD mod_cache HttpCacheAction: where is 304?

Following to http://wiki.apache.org/cocoon/ControllingModCache I found this class: org.apache.cocoon.acting.HttpCacheAction (dated 2004-07-29) Unfortunately, this action can't reply with 304 on request with HTTP Header [If-Modified-Since: ..] It replies only with 200 and full body of dynami