Re: [wsrp] [AJAX] Redirect behavior - clarification

[Rich Thompson <richt2@us.ibm.com>]

The semantics of returning a redirectURL
break when the redirect header is silently set on the XHR response. The
semantics would be maintained if instead the server-side Consumer component
communicated the redirect to the browser-side Consumer component which
then redirected the entire page.

I think the key point is that the protocol
semantics have to be honored by the Consumer despite the splitting of its
components across the network boundary. Requiring the entire system to
be aware of, and adapt to, a particular deployment choice of the Consumer
would introduce significant complexity without any offsetting value.

Rich

Subbu Allamaraju <subbu@bea.com>

05/11/06 12:55 AM

To	Rich Thompson/Watson/IBM@IBMUS
cc	wsrp@lists.oasis-open.org
Subject	Re: [wsrp] [AJAX] Redirect behavior - clarification

Consider the following sequence:

An event occurs in the UA
    -> Consumer-generated script sends an XHR to the Consumer
       -> Consumer sends a pbia request to the Producer
       <- Producer returns a redirectURL
    <- Consumer sends a redirect header back to the UA
    -> XHR will silently follow the redirect
    <- XHR obtains the response from the redirect source
    -> XHR invokes consumer's onreadystatechange function
       with the response

Upon redirect, the script is still in charge. Also the fact that 
browsers follow the redirect silently (at least in the browsers I tested
with) makes this case different from the normal redirect case, and 
requires the consumer's onreadystatechange function to handle the response.

Subbu

Rich Thompson wrote:
> 
> I don't see why the Portlet's callback function would ever get called
if 
> pbia() returns a redirectURL. The semantics of redirecting the user
> applies to the page and so normally gm() is usually not invoked on
any 
> of the Portlets. How the Consumer chooses to communicate this between
> its server and browser components is an implementation decision, but
the 
> semantics for both the Portlet and End-User should be identical to
the 
> server-side aggregation case.
> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 05/10/06 01:16 AM
> 
>                  
> To
>                  Rich
Thompson/Watson/IBM@IBMUS
> cc
>                  wsrp@lists.oasis-open.org
> Subject
>                  Re:
[wsrp] [AJAX] Redirect behavior - clarification
> 
> 
>                  
> 
> 
> 
> 
> 
> The context is a redirect response to an XMLHttpRequest for the
> consumer-aided AJAX case. In this case, the redirect is handled at
the
> XMLHttpRequest level, and the consumer script that made the request
> would receive the response from the redirect target.
> 
> In non-redirect cases, the consumer can create the response payload
for
> XHR requests, and it knows what to expect from the response. In the
> redirect case, the consumer can assume that the response solely belongs
> to the portlet's callback. The more I think about this, this seems
> reasonable. I'm just remarking that the consumer implementations will
> have to handle this case.
> 
> Subbu
> 
> 
> Rich Thompson wrote:
>  >
>  > I'm sorry, but the context for your question appears to
be missing. I
>  > presume you are asking about a situation where the Consumer
is providing
>  > some sort of client-side aggregation and that pbia() has
returned a
>  > redirectURL. If that is your question, I do not see why
the semantics
>  > would be any different than it is today, namely that the
Consumer will
>  > redirect the End-User to the new URL. Are you proposing
changing this
>  > portion of the protocol's semantics, or that moving the
network tier
>  > where aggregation occurs should change the semantics or
something else
>  > altogether?
>  >
>  > Rich
>  >
>  >
>  > *subbu@bea.com*
>  >
>  > 05/09/06 03:24 PM
>  >
>  >                
 
>  > To
>  >                
 wsrp@lists.oasis-open.org
>  > cc
>  >                
 
>  > Subject
>  >                
 [wsrp] [AJAX] Redirect behavior - clarification
>  >
>  >
>  >                
 
>  >
>  >
>  >
>  >
>  >
>  > When I raised the question of semantics of redirectURL,
it was suggested
>  > that it can be treated as a regular full-page redirect.
I would like to
>  > get some clarification on the behavior.
>  >
>  > When a browser submits an XHR and encounters a redirect,
the browser
>  > would follow the redirect and send the final response to
the script.
>  > Since the redirect target will most likely be outside the
consumer, the
>  > consumer cannot include its own response when a redirect
happens. As a
>  > result, the (consumer supplied) client side script may
not be able to
>  > understand the response.
>  >
>  > I see three options:
>  >
>  > a. Disallow redirects.
>  >
>  > b. Let the consumer handle the redirect, and capture the
response. This
>  > would give the consumer a chance to include its own response.
>  >
>  > c. Let the consumer send a redirect header to the browser,
and comment
>  > that consumer's script may just get the portlet's data/markup
in the
>  > response, and it should be ready to deal with it.
>  >
>  > I vote for (c). Any comments?
>  >
>  > Subbu
>  >
>  > ---------------------------------------------------------------------
To
>  > unsubscribe from this mail list, you must leave the OASIS
TC that
>  > generates this mail. You may a link to this group and all
your TCs in
>  > OASIS at:
>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may
contain
> information  of  BEA Systems,  Inc.,  its subsidiaries
 and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted
 and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return
this
> by email and then delete it.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your
TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
To 
> unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs
in 
> OASIS at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries
 and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted
 and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php