[#DWR-421] Support for custom handling on client side of redirect server response - DWR

Details

Type: Improvement
Status: Resolved
Priority: Normal
Resolution: Fixed
Affects Version/s: 2.0.5
Fix Version/s: 3.0.RC3
Component/s: Engine

Documentation Required:
Yes

Description:

Hide
Please implement support for custom handling on client (browser) side of redirect server response to a dwr call.

Currently textHtmlHandler only captures 200 OK responses with non-empty content, so situation when e.g. Spring security filter chain handles request on an expired session (and thus expired security context) request might not get to DWR servlet (spring security filter chain being registered before dwr servlet), Spring security will typically respond with redirect response to authentication processing filter entry point (a login page) with status code 302 and empty response content.

Support could be through additional dwr.engine._redirectHandler adjustable through dwr.engine.setRedirectHandler. By default it could be same as defaultTextHtmlHandler. One could then override redirectHandler setting and provide custom handler for redirect response, even use same custom handler as both redirect and textHtml handler, but with flexibility to use different one for each case.

How to set redirectHandler should also be documented at least at [Error Handling documentation|http://directwebremoting.org/dwr/other/errors.html] page.

Show
Please implement support for custom handling on client (browser) side of redirect server response to a dwr call. Currently textHtmlHandler only captures 200 OK responses with non-empty content, so situation when e.g. Spring security filter chain handles request on an expired session (and thus expired security context) request might not get to DWR servlet (spring security filter chain being registered before dwr servlet), Spring security will typically respond with redirect response to authentication processing filter entry point (a login page) with status code 302 and empty response content. Support could be through additional dwr.engine._redirectHandler adjustable through dwr.engine.setRedirectHandler. By default it could be same as defaultTextHtmlHandler. One could then override redirectHandler setting and provide custom handler for redirect response, even use same custom handler as both redirect and textHtml handler, but with flexibility to use different one for each case. How to set redirectHandler should also be documented at least at [Error Handling documentation|http://directwebremoting.org/dwr/other/errors.html] page.

Issue Links

Relationship

This issue is related to:
~~DWR-508~~ textHtmlHandler not being called when remoting via iframe (uploads)

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

David Marginian added a comment - 07/Oct/09 2:30 PM

Stevo,
It will probably take us awhile to get to this. If you would like to take a stab at fixing it and submit a patch that would be great. It should be pretty straightforward to do it (just look at the other handlers in engine.js).

Show

David Marginian added a comment - 07/Oct/09 2:30 PM Stevo, It will probably take us awhile to get to this. If you would like to take a stab at fixing it and submit a patch that would be great. It should be pretty straightforward to do it (just look at the other handlers in engine.js).

Hide

Permalink

David Marginian added a comment - 12/Dec/11 5:08 PM - edited

Mike, you ok with this as described? I know you have had some other ideas here about renaming textHtmlHandler and expanding it to handle other status codes:
(http://dwr.2114559.n2.nabble.com/DWR-RC2-with-reverse-ajax-textHtmlHandler-warningHandler-behavior-and-server-down-tt6650184.html#a6721465)

"Yes, I've previosuly been thinking that our textHtmlHandler is a bit "asymmetric", in that we provide a handler for one very specific response type but none for others, such as redirects. I would either like to see us widen the scope of the textHtmlHandler (possibly renaming it) or provide another handler for other unexpected responses that are not errors. The reasoning in ~~DWR-421~~ sounds good but maybe we should look through other potential response types before deciding on handler names."

It seems to me redirect status codes and text/html responses will always be handled in the same manner. So deprecating the existing handler and creating a new one that will handle both situations seems to make sense. The trick is coming up with a reasonable name for it.

Show

David Marginian added a comment - 12/Dec/11 5:08 PM - edited Mike, you ok with this as described? I know you have had some other ideas here about renaming textHtmlHandler and expanding it to handle other status codes: (http://dwr.2114559.n2.nabble.com/DWR-RC2-with-reverse-ajax-textHtmlHandler-warningHandler-behavior-and-server-down-tt6650184.html#a6721465) "Yes, I've previosuly been thinking that our textHtmlHandler is a bit "asymmetric", in that we provide a handler for one very specific response type but none for others, such as redirects. I would either like to see us widen the scope of the textHtmlHandler (possibly renaming it) or provide another handler for other unexpected responses that are not errors. The reasoning in ~~DWR-421~~ sounds good but maybe we should look through other potential response types before deciding on handler names." It seems to me redirect status codes and text/html responses will always be handled in the same manner. So deprecating the existing handler and creating a new one that will handle both situations seems to make sense. The trick is coming up with a reasonable name for it.

Hide

Permalink

David Marginian added a comment - 23/Dec/11 11:14 AM

Mike, I have checked in a fix for this for your review.

1) I created a new handler called textOrRedirectHandler that can handle both 300 level status codes and text/html responses.
2) I have left textHtmlHandler in place. It can be used with textOrRedirectHandler to handle text/html responses separately from 300 level status codes (not that this is likely to be required but it is not much additional code so why not?).

Show

David Marginian added a comment - 23/Dec/11 11:14 AM Mike, I have checked in a fix for this for your review. 1) I created a new handler called textOrRedirectHandler that can handle both 300 level status codes and text/html responses. 2) I have left textHtmlHandler in place. It can be used with textOrRedirectHandler to handle text/html responses separately from 300 level status codes (not that this is likely to be required but it is not much additional code so why not?).

Hide

Permalink

David Marginian added a comment - 05/Dec/12 7:04 PM

Mike, the code for this is actually done and has been checked in.

Show

David Marginian added a comment - 05/Dec/12 7:04 PM Mike, the code for this is actually done and has been checked in.

Hide

Permalink

Mike Wilson added a comment - 07/Dec/12 1:18 AM

Great, that's the best kind of JIRA ticket - the already fixed one!
Should it be resolved?

Show

Mike Wilson added a comment - 07/Dec/12 1:18 AM Great, that's the best kind of JIRA ticket - the already fixed one! Should it be resolved?

Hide

Permalink

David Marginian added a comment - 07/Dec/12 4:21 AM

Sure I will resolve it. Wasn't sure if you wanted to take a look at what I had done.

Show

David Marginian added a comment - 07/Dec/12 4:21 AM Sure I will resolve it. Wasn't sure if you wanted to take a look at what I had done.

Hide

Permalink

David Marginian added a comment - 07/Dec/12 4:21 AM

Documentation needs to be written.

Show

David Marginian added a comment - 07/Dec/12 4:21 AM Documentation needs to be written.

People

Assignee:

David Marginian

Reporter:

Stevo Slavic
Votes:

2

Watchers:

4

Dates

Created:

07/Oct/09 10:17 AM

Updated:

04/Mar/13 9:27 AM

Resolved:

07/Dec/12 4:21 AM