Major Description
This was originally posted as a ConcurrentModificationException during detach on the wicket user list (http://markmail.org/message/xnrot5hm4wvow7dq) but later investigations show that there is something else not right.
Let me begin by restating the original problem:
A couple of days ago Warren came to me with a problem. If he attached
a behavior to a component which potentially throws a
RestartResponseAtInterceptPageException a
ConcurrentModificationException would bubble all the way into tomcat
code.
Now you probably are going to say: "Then don't do that" 
but the
fact that an exception escapes wicket is imo reason to investigate.
So i did some digging. The situation is as follows:
In the renderHead method of an IHeaderContributor a check is performed
for an authenticated user, if none is found a RRAIPE is thrown.
One of the places that executes renderHead is the onDetach of WebPage.
Now suppose we have a Page A which has a component decorated with this
header contributor, the page also contains a Button to log off users.
The onsubmit for this button is as simple as log user off and
setResponsePage(class).
This page is usually only accessible if an authenticated user is
available so everything works fine if that is the case.
But then the user decides to log off, the onsubmit is triggered and
exits normally. the request continues and reaches the point where the
RequestCycle is detaching all RequestTargets (at that point there are
2 targets, 1 for the current page and 1 set during the onsubmit).
During the detach the renderHead method is executed along with the
check for an authenticated user. Since there isn't one anymore a
RRAIPE is thrown, adding a 3rd target to the stack of RequestTargets.
The RRAIPE bubbles up to RequestCycle.detach() and is caught and
logged there. Then wicket attempts to detach the next RequestTarget
but since an iterator is used to loop through all targets, the
iterator detects the stack has been changed and throws a
ConcurrentModificationException. Ultimately resulting in a tomcat
error page.
I tried changing the iterator loop to a regular for(int i=0;i < .....)
loop and this seems to fix the problem, even if later on more
requesttargets are added wicket happily executes them and comes up
with the desire page.
There is one disadvantage i see with this solution: the requesttarget
throwing the RRAIPE is not fully detached. Perhaps the RRAIPE can be
swallowed after it has added a RequestTarget and only in the case of a
detach phase. That way the rest of the page could be normally
detached.
Here is where it gets interesting:
Johan noticed that WebPage.detach should not call renderHead during detach.
In fact the only reason it does so is during development when it does not detect a header element. It then checks if there indeed should not be a header by visiting the behaviors and comparing the output to what it currently has. However as the code comments point out it then does nothing with that information because the code that should handle it does not work yet.
So the question became why does the page does not have a header element. At first i thought this is because in this case a setResponsePage is done which would suppress any rendering of the current page.
However this is not the case as renderhead is also called during detach in a normal page render. It does not matter if the markupfile contains a header element or not. As it turns out the presence of a header element is checked by getting a wicket component with id header This always returns null as there is no such child component. There is however a child component with an id like _header_0