You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Eric SCHAEFFER <es...@posterconseil.com> on 2000/01/28 17:36:10 UTC
HTTP headers (redirect and so on..)
Hi,
I posted a proposal a few days ago to implement a processor for HTTP
headers, but didn't receive any response. Do you think it's a bad idea ?
I've implemented it because I needed HTTP redirect functionnality, and it
seem's that I'm not the only one...
Eric.
_______________________________________
Eric SCHAEFFER
eschaeffer@posterconseil.com
POSTER CONSEIL
118 rue de Tocqueville
75017 PARIS
FRANCE
Tel. : 33-140541058
Fax : 33-140541059
----------------------------------------------------------------------------
-----------------------------
Come to the first official Apache Software Foundation Conference!
-----------------------------------
http://ApacheCon.Com ------------------------------------
_______________________________________
Re: HTTP headers (redirect and so on..)
Posted by Stefano Mazzocchi <st...@apache.org>.
Eric SCHAEFFER wrote:
> > > But I've got another problem : XSP pages are compiled and cached in the
> > > repository. They can be recovered by their URL. Good.
> > > But what if it's my producer that return different XML documents
> depending
> > > on the context ?
> >
> > That should _not_ be handled by your producer, but the sitemap should
> > call the right producer depending on some rules or some matching class.
> >
>
> I put my code there because it's the only 'process' that is in top of each
> request. My code performs restriction access and security ckecks. In ASP or
> others, if you want to do that, you need to do it in every page. That's
> definitively not the good solution. We should be able to do it at the Web
> Server level. And if I want to use HttpSession, I need to do it at the
> Servlet Engine level. For now, Cocoon is associated only to xml files, but I
> would like to 'protect' all my ressources with a unique method (it would be
> perfect). I don't really know how to do it...
> I haven't tried the sitemap yet. Do I need to install Tomcat ? (I don't
> really know what is the 'sitemap', sorry...).
The sitemap is a proposal some of us made a while ago about a central
point of management of all the pages handled by cocoon. Something that
would exactly match what you're looking for.
> > > I wrote a producer that perform some verifications before reading the
> XML
> > > file, and redirect the client to another URL when a error occures.
> > > As the producers can't write directly in the response object, my
> producer
> > > return an XML document to perform the redirect. If I return an XSP page,
> and
> > > if it's already catched, it isn't recompiled and no redirect is
> performed...
> >
> > ? the redirect tells the browser to request another URI which can be
> > handled by another XSP. I don't see the problem. Are you talking about
> > internal redirection?
>
> Here is a big problem (or mistake). When you write a Web application (or
> site), the only thing that the final user sees is the URL of the current
> page. Frames have been removed everywhere because it breaks the 'Web logic'
> : you always see only one URL, but you can display other pages (you don't
> know where you are, you can't bookmark the current page, etc...).
> If you do an internal redirect (witch I can do in my producer because it can
> choose to return the XML document it want), you also break the 'Web logic'.
> I don't want to do an internal redirect, I want a true HTTP redirect.
> Internal redirects are good for internal problems and processing...
>
> The problem is that XSP pages are compiled in the repository. If the first
> time a page is requested, everything is Ok, then the compiled page is the
> 'true' page. Now, at the second request, the processor detects an error and
> wants to redirect the client to the error page. It then returns an XML
> document containing XSP code to perform the redirect. As the page is already
> compiled, the Cocoon engine call the cached version, that is the good one.
> Do you see what I mean ?
Then you need to place the "error detection" logic inside your XSP or
before it is executed. For the first option, you have what you need. For
the second, you need the sitemap.
Since nobody seems working on the sitemap anymore, I'll do it as soon as
I have time.
> Doing like this is not the good way. I shouldn't have to return an XML
> document to do a redirect...
What's wrong with using XSP for that?
> >
> > > My question is : why producers can't have access to the response object
> ?
> >
> > Because they should not be able to mess with the output stream directly.
> > We all agreed that a better Request/Response model should be defined,
> > and that producers should have access to _some_ response methods, but
> > not all.
> >
> > Niclas told me he's going to propose a better API for Request and
> > Response objects. We should wait for his proposal before dive into this
> > more deeply.
>
> Ok.
> I will use my old redirect processor until a decision is make.
Or use XSP with internal error catching logic.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: HTTP headers (redirect and so on..)
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
----- Original Message -----
From: Stefano Mazzocchi <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Monday, January 31, 2000 8:17 PM
Subject: Re: HTTP headers (redirect and so on..)
> Eric SCHAEFFER wrote:
> >
> > Youps, sorry. I misunderstood something (+ I thought that if the
document
> > was null in Engine.java, it could raise an NullPointerException or
something
> > like that).
> > I'm confused...
>
> I think that setting the output to null should be discouradged. I
> discussed with Eric before and i think we should have a
> StopProcessingSignal throwable class that can be thrown to signal the
> end of the processing.
>
> But in case SAX is used, you should call closeDocument() and terminate
> that. I think we should leave the return null hack for now and thinking
> about correct SAX handling in the future.
+1
>
> > (But you don't return null, you set the document variable to null in
your
> > XSP page because the populateDocument function doesn't return anything.)
>
> ??
I just wanted to say that, when you request for an XSP page, the XML
document is tranformed in a java file by the XSP engine, and the method
called to have the final output is 'populateDocument' in this class. This
method 'return' void, thus you have to set the 'document' variable to null
and not return null. That's all.
(Not very important, but ...)
>
> > But I've got another problem : XSP pages are compiled and cached in the
> > repository. They can be recovered by their URL. Good.
> > But what if it's my producer that return different XML documents
depending
> > on the context ?
>
> That should _not_ be handled by your producer, but the sitemap should
> call the right producer depending on some rules or some matching class.
>
I put my code there because it's the only 'process' that is in top of each
request. My code performs restriction access and security ckecks. In ASP or
others, if you want to do that, you need to do it in every page. That's
definitively not the good solution. We should be able to do it at the Web
Server level. And if I want to use HttpSession, I need to do it at the
Servlet Engine level. For now, Cocoon is associated only to xml files, but I
would like to 'protect' all my ressources with a unique method (it would be
perfect). I don't really know how to do it...
I haven't tried the sitemap yet. Do I need to install Tomcat ? (I don't
really know what is the 'sitemap', sorry...).
> > I wrote a producer that perform some verifications before reading the
XML
> > file, and redirect the client to another URL when a error occures.
> > As the producers can't write directly in the response object, my
producer
> > return an XML document to perform the redirect. If I return an XSP page,
and
> > if it's already catched, it isn't recompiled and no redirect is
performed...
>
> ? the redirect tells the browser to request another URI which can be
> handled by another XSP. I don't see the problem. Are you talking about
> internal redirection?
Here is a big problem (or mistake). When you write a Web application (or
site), the only thing that the final user sees is the URL of the current
page. Frames have been removed everywhere because it breaks the 'Web logic'
: you always see only one URL, but you can display other pages (you don't
know where you are, you can't bookmark the current page, etc...).
If you do an internal redirect (witch I can do in my producer because it can
choose to return the XML document it want), you also break the 'Web logic'.
I don't want to do an internal redirect, I want a true HTTP redirect.
Internal redirects are good for internal problems and processing...
The problem is that XSP pages are compiled in the repository. If the first
time a page is requested, everything is Ok, then the compiled page is the
'true' page. Now, at the second request, the processor detects an error and
wants to redirect the client to the error page. It then returns an XML
document containing XSP code to perform the redirect. As the page is already
compiled, the Cocoon engine call the cached version, that is the good one.
Do you see what I mean ?
Doing like this is not the good way. I shouldn't have to return an XML
document to do a redirect...
>
> > My question is : why producers can't have access to the response object
?
>
> Because they should not be able to mess with the output stream directly.
> We all agreed that a better Request/Response model should be defined,
> and that producers should have access to _some_ response methods, but
> not all.
>
> Niclas told me he's going to propose a better API for Request and
> Response objects. We should wait for his proposal before dive into this
> more deeply.
Ok.
I will use my old redirect processor until a decision is make.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------
>
>
_______________________________________
Eric SCHAEFFER
eschaeffer@posterconseil.com
POSTER CONSEIL
118 rue de Tocqueville
75017 PARIS
FRANCE
Tel. : 33-140541058
Fax : 33-140541059
----------------------------------------------------------------------------
-----------------------------
Come to the first official Apache Software Foundation Conference!
-----------------------------------
http://ApacheCon.Com ------------------------------------
_______________________________________
Re: HTTP headers (redirect and so on..)
Posted by Mike Engelhart <me...@earthtrip.com>.
Stefano Mazzocchi wrote:
>
> ? the redirect tells the browser to request another URI which can be
> handled by another XSP. I don't see the problem. Are you talking about
> internal redirection?
hmmm...I didn't write that but, is there any way to do an internal redirect?
This is exactly what I need to do and why I brought the RequestDispatcher
issue.
Re: HTTP headers (redirect and so on..)
Posted by Stefano Mazzocchi <st...@apache.org>.
Eric SCHAEFFER wrote:
>
> Youps, sorry. I misunderstood something (+ I thought that if the document
> was null in Engine.java, it could raise an NullPointerException or something
> like that).
> I'm confused...
I think that setting the output to null should be discouradged. I
discussed with Eric before and i think we should have a
StopProcessingSignal throwable class that can be thrown to signal the
end of the processing.
But in case SAX is used, you should call closeDocument() and terminate
that. I think we should leave the return null hack for now and thinking
about correct SAX handling in the future.
> (But you don't return null, you set the document variable to null in your
> XSP page because the populateDocument function doesn't return anything.)
??
> But I've got another problem : XSP pages are compiled and cached in the
> repository. They can be recovered by their URL. Good.
> But what if it's my producer that return different XML documents depending
> on the context ?
That should _not_ be handled by your producer, but the sitemap should
call the right producer depending on some rules or some matching class.
> I wrote a producer that perform some verifications before reading the XML
> file, and redirect the client to another URL when a error occures.
> As the producers can't write directly in the response object, my producer
> return an XML document to perform the redirect. If I return an XSP page, and
> if it's already catched, it isn't recompiled and no redirect is performed...
? the redirect tells the browser to request another URI which can be
handled by another XSP. I don't see the problem. Are you talking about
internal redirection?
> My question is : why producers can't have access to the response object ?
Because they should not be able to mess with the output stream directly.
We all agreed that a better Request/Response model should be defined,
and that producers should have access to _some_ response methods, but
not all.
Niclas told me he's going to propose a better API for Request and
Response objects. We should wait for his proposal before dive into this
more deeply.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: HTTP headers (redirect and so on..)
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
Youps, sorry. I misunderstood something (+ I thought that if the document
was null in Engine.java, it could raise an NullPointerException or something
like that).
I'm confused...
(But you don't return null, you set the document variable to null in your
XSP page because the populateDocument function doesn't return anything.)
But I've got another problem : XSP pages are compiled and cached in the
repository. They can be recovered by their URL. Good.
But what if it's my producer that return different XML documents depending
on the context ?
I wrote a producer that perform some verifications before reading the XML
file, and redirect the client to another URL when a error occures.
As the producers can't write directly in the response object, my producer
return an XML document to perform the redirect. If I return an XSP page, and
if it's already catched, it isn't recompiled and no redirect is performed...
My question is : why producers can't have access to the response object ?
Eric.
_______________________________________
Eric SCHAEFFER
eschaeffer@posterconseil.com
POSTER CONSEIL
118 rue de Tocqueville
75017 PARIS
FRANCE
Tel. : 33-140541058
Fax : 33-140541059
----------------------------------------------------------------------------
-----------------------------
Come to the first official Apache Software Foundation Conference!
-----------------------------------
http://ApacheCon.Com ------------------------------------
_______________________________________
----- Original Message -----
From: Mike Engelhart <me...@earthtrip.com>
To: <co...@xml.apache.org>
Sent: Monday, January 31, 2000 4:53 PM
Subject: Re: HTTP headers (redirect and so on..)
> Eric SCHAEFFER wrote:
>
> > I've been using XSP for just 1 week (before I used DCP).
> >
> > But how do you stop Cocoon processing ? You write the redirect code at
the
> > top of the file (before other PIs) ?
> >
> > I still believe that we need to modify the Engine class... (signal that
stop
> > the Cocoon processing)
> >
> > Eric.
> As I said, just put a "return null;" after the sendRedirect() call. That
> effectively ends that Producer's getDocument() call which is what is being
> processed?
>
> As I said in the other post, I'm not sure what you mean about other PI's??
>
Re: HTTP headers (redirect and so on..)
Posted by Mike Engelhart <me...@earthtrip.com>.
Eric SCHAEFFER wrote:
> I've been using XSP for just 1 week (before I used DCP).
>
> But how do you stop Cocoon processing ? You write the redirect code at the
> top of the file (before other PIs) ?
>
> I still believe that we need to modify the Engine class... (signal that stop
> the Cocoon processing)
>
> Eric.
As I said, just put a "return null;" after the sendRedirect() call. That
effectively ends that Producer's getDocument() call which is what is being
processed?
As I said in the other post, I'm not sure what you mean about other PI's??
Re: HTTP headers (redirect and so on..)
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
I've been using XSP for just 1 week (before I used DCP).
But how do you stop Cocoon processing ? You write the redirect code at the
top of the file (before other PIs) ?
I still believe that we need to modify the Engine class... (signal that stop
the Cocoon processing)
Eric.
_______________________________________
Eric SCHAEFFER
eschaeffer@posterconseil.com
POSTER CONSEIL
118 rue de Tocqueville
75017 PARIS
FRANCE
Tel. : 33-140541058
Fax : 33-140541059
----------------------------------------------------------------------------
-----------------------------
Come to the first official Apache Software Foundation Conference!
-----------------------------------
http://ApacheCon.Com ------------------------------------
_______________________________________
----- Original Message -----
From: Mike Engelhart <me...@earthtrip.com>
To: <co...@xml.apache.org>
Sent: Friday, January 28, 2000 6:41 PM
Subject: Re: HTTP headers (redirect and so on..)
> Eric SCHAEFFER wrote:
>
> > Hi,
> >
> > I posted a proposal a few days ago to implement a processor for HTTP
> > headers, but didn't receive any response. Do you think it's a bad idea ?
> >
> > I've implemented it because I needed HTTP redirect functionnality, and
it
> > seem's that I'm not the only one...
> >
> >
> > Eric.
> Does XSP work for you?
>
> I've been using XSP to do redirects for a couple of weeks...
>
> <xsp:logic>
> response.sendRedirect("project/something.xml");
> return;
> </xsp:logic>
>
>
> Mike
>
Re: HTTP headers (redirect and so on..)
Posted by Mike Engelhart <me...@earthtrip.com>.
Eric SCHAEFFER wrote:
> Hi,
>
> I posted a proposal a few days ago to implement a processor for HTTP
> headers, but didn't receive any response. Do you think it's a bad idea ?
>
> I've implemented it because I needed HTTP redirect functionnality, and it
> seem's that I'm not the only one...
>
>
> Eric.
Does XSP work for you?
I've been using XSP to do redirects for a couple of weeks...
<xsp:logic>
response.sendRedirect("project/something.xml");
return;
</xsp:logic>
Mike