G�rard V wrote: > Denver B wrote: > > The message "HTTP request failed, unable to process HyperEvent" is generated by > > the Java program cspbroker.class. > > (You need to open your Java console to see the details. > > If there isn't enough detail, see my post about turning on debug mode.) > > However, the problem is most likely with whatever COS code the hyperevent is > > calling. > 1) URL ReWriting > I use the ReWriting mechanism of Apache (it's just to have only .html > extension instead of .csp and to mask the /csp/... prefix) Did you say that it works when you turn off URL rewriting?
> I think the consequence is that I lose the right url path to > CSPBrokerApplet That's not possible since the error message clearly tells me that the applet is running. > or the path to the subroutine called by the CSPBrokerApplet. I think that whatever Apache does, it should be able to decode without loss of information. But perhaps it doesn't. The URL strings having been re-written by Cache' become rather long. Perhaps when Apache re-writes them, they become so long (>2Kb) that the browser can't processes them. Did you view-source? What do you see in the Java console? > 2) OnPageBody ... > To be able to use the CSP:SEARCH in an included page I must put <html> and > <body> in the included page. > If I don't put them in the included page I have the error message. That's is simply a matter of shifting the problem around. > But I don't know if this is W3C compliant? No, it certainly is not. > And If it is the good way (or the good work around) to solve this problem. No, it is not. Could it be fooling Apache somehow? I don't know, I don't see what the real problem is.
