[CO1224] TOO MANY REDIRECTS DURING PETITION PROCESSING HITS FIREFOX

[CO1224] TOO MANY REDIRECTS DURING PETITION PROCESSING HITS FIREFOX




[#CO-1224] too many redirects during petition processing hits Firefox redirection limit

[CO-1224] too many redirects during petition processing hits Firefox redirection limit Created: 10/Apr/16  Updated: 01/Jun/19  Resolved: 11/Apr/16

Status:

Resolved

Project:

COmanage

Component/s:

Registry

Affects Version/s:

COmanage Registry 1.0.2 (Polished Polygon MR2)

Fix Version/s:

COmanage Registry 1.0.3 (Polished Polygon MR3)


Type:

Bug

Priority:

Critical

Reporter:

Scott Koranda SCG (Inactive)

Assignee:

Arlen Johnson (google.com)

Resolution:

Fixed

Votes:

0

Labels:

CMF-I2T

Remaining Estimate:

Not Specified

Time Spent:

Not Specified

Original Estimate:

Not Specified



 Description 

 

During the processing of petitions it is possible for the responses returned by Registry to be a series that only includes HTTP response code 302, that is a redirect. The Firefox browser has a default limit to the number of 302 redirects that it will follow before displaying an error to the user. The default is 20. Note that the series of redirects need not include a loop for Firefox to stop processing and display the error page.

With an enrollment plugin(s) configured it is possible for Registry to return a series of more than 20 redirects and for the user to see the Firefox error page even though the enrollment petition flow and the process would otherwise be valid.

The Firefox setting, accessible from the 'about:config' page is

network.http.redirection-limit

See also

http://kb.mozillazine.org/Network.http.redirection-limit

and

https://bugzilla.mozilla.org/show_bug.cgi?id=83471


 Comments 

 

Comment by benno [ 10/Apr/16 ]

Initial implementation in 722b592d8c.

To Arlen to make it prettier.

Comment by scott.koranda [ 11/Apr/16 ]

Testing shows a series of plain text messages as expected. For example:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>
Processing request, please wait... </title>

<meta http-equiv="refresh" content="0;URL='/registry/co_petitions/finalize/985/token:c236d7d977103f2aeb9ea47b06a9aa14badee902'" />
</head>
<body>
<div id="container">
<div id="content">
Initiating Finalize step, please wait... </div>
</div>
</body>
</html>

Comment by benno [ 11/Apr/16 ]

Scott points out that meta-refresh is deprecated. Perhaps we should use javascript instead.

Comment by spartanicus [ 11/Apr/16 ]

A switch to JavaScript is simple - however, this may be an unusual case in which we are attempting a browser workaround to replace server-side redirection because normal server-side redirection breaks the browser. That being the case, the meta-refresh is the more appropriate approach because it leads to expected behavior: the back button should jump back over the redirect pages and land on the starting page (just as it would were these server-side redirects). The JavaScript approach will not - the user will jump back over each redirect page (that will then attempt to bounce them forward.)

wrt usability, neither approach in the client is better, but as a workaround, the meta approach is for the aforementioned reasons. Meta refresh is not itself deprecated in HTML 5 - it's discouraged for normal redirection that should take place on the server wrt WCAG. (Now reference paragraph one.)

For future reference, here's javascript:

// Use setTimeout to allow for a slight delay before each redirect.
 
// Set timeout value to zero to remove the delay.
 
setTimeout(function() {
 
  window.location.href = "<?php print $this->Html->url($vv_meta_redirect_target); ?>";
 
}, 0);

Comment by spartanicus [ 11/Apr/16 ]

Completed as of 6b37890

Generated at Sun Nov 21 23:05:17 UTC 2021 using Jira 8.20.1#820001-sha1:6d4b94dbcc29d26a5651b231dd69e39cd4357315.





Tags: during petition, description during, processing, redirects, firefox, [co1224], petition, during