OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


That's an interesting argument, but I find it unnatural for developers 
using XHR to fetch fragments.

Here the portlet made the choice to use consumer-supplied XHR, and the 
behavior the portlet dev would see must be consistent with what would 
happen when a web dev uses XHR, and the resource redirects. When this 
happens, the user does not see the new page, the XHR sees the new page. 
I would argue that the same behavior must be honored when the same web 
app is aggregated as a portlet. WSRP's redirect style only makes sense 
only when the redirect response is sent to a full page request. What's 
the point in imposing an unnatural redirect style?

Subbu

Rich Thompson wrote:
> 
> 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
> 
> 
> --------------------------------------------------------------------- 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]