Http Analyzer shows the following when clicking on a link to start a flow (http://localhost:8500/Lock/app.jsf?_...ate-individual) :
I only recorded the first request, as things start to go wrong there (2 threads spawned when using Firefox).
GET /Lock/app.jsf;jsessionid=G6lQTqVJnX20k7hkdLCS3R78GTh9Qbr8z7b3bkLynrLLJKCtnB02!1997995148?_flowExecutionKey=_c94FD9D30-26A2-E06C-CF3C-90BE5F8E7335_k6F1D16D9-951B-5756-520B-E0AB105B7714 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20070309 Firefox/184.108.40.206
GET /Lock/app.jsf?_flowExecutionKey=_c008D2299-3A04-4DD0-0553-F61D9F8BBDAE_k22D12B1B-770F-9FB0-1245-73262D2B00D2 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Firefox doesn't send a cookie with the request, IE does
Firefox adds Keep-Alive: 300, IE doesn't
On Tomcat, Firefox does send a cookie with the request
I added a watchpoint on continuations in FlowExecutionContinuationGroup to show the 2 active threads in my debugger.
I did have a question about the processing order , why does the redirection occur (BEFORE RENDER RESPONSE) before saving the flow execution (AFTER RENDER RESPONSE).
I find this particular problem just as whacky as you do, but I was just wondering why the redirect is called before saving the flowexecution.