View Bug #524
Summary: Add $m->internal_redirect (was: $m->abort and $m->redirect do not propagate out of subrequest)
| Difficulty: 2 | Version goal: 1.3x | ||||
| Status: Unassigned | |||||
| Version found: 1.10 | Severity: Normal |
Description
If a subrequest performs a $m->abort or $m->redirect, it does not reach the parent request other than by returning a value from $m->subexec (which most people don't check).
The current behavior is consistent with requests in general. Making $m->abort propagate would make subrequests more like component calls in this regard. I'm not sure which behavior is more correct. Whatever we do, it needs to be documented.
[This is just one of a variety of cases in which we have to decide whether subrequests act like requests, or like glorified component calls. We need to flush out all these cases and document them, even if we don't change the behavior.]
One solution would be to add a Request parameter (say propagate_abort) that causes aborts to be propagated out of the request. In the stable branch this would have to be set manually in subrequests to avoid backwards incompatibility, but in future branches this could be set by default in a subrequest. This is cleaner, IMO, than checking $m->is_subrequest specifically to determine abort behavior.
See also $m->internal_redirect idea in comments.
History
| Jonathan Swartz created bug. | ||
| Jonathan Swartz set version_found to 1.10. | ||
| Jonathan Swartz set difficulty to 2. | ||
| Jonathan Swartz set severity to Normal. | ||
|
Jonathan Swartz
writes: Here's another idea: Add yet another API to subrequests, called $m->internal_redirect. This would call $m->subexec, then immediately abort afterwards with any value returned. That way people could choose which behavior they wanted ($m->internal_redirect would be most popular, probably).
|
||
| Jonathan Swartz modified summary. |