Bugzilla dups for Handling of Wrapped Responses

[Tim Funk <fu...@joedog.org>]

 From the recent bug report about wrapped responses vs .forward() I did this 
query: Search on description "wrapped request forward"

http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Tomcat+4&short_desc=&short_desc_type=allwordssubstr&long_desc=wrapped+request+forward&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time


Turned up each of the bugs in question ...
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8566
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11335
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16032
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9754 	
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11366
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20314

Are all of there dups of one another?

-Tim


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: Bugzilla dups for Handling of Wrapped Responses

[Remy Maucherat <re...@apache.org>]

Tim Funk wrote:
>  From the recent bug report about wrapped responses vs .forward() I did 
> this query: Search on description "wrapped request forward"
> 
> http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Tomcat+4&short_desc=&short_desc_type=allwordssubstr&long_desc=wrapped+request+forward&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time 
> 
> 
> 
> Turned up each of the bugs in question ...
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8566

The resolution and comments are correct, apparently. We don't quite do 
that right now, and it seems fixed if you looks at 4.1.x behavior.

> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11335

That one seems bad with respect to the spec (no wrapping is supposed to 
occur, so we reflect whatever path the wrapped request wants to). 
There's a contradiction, though. That bug probably doesn't exist anymore 
with 4.1.x since we wrap.

> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16032

That's probably fixed now (not too sure).

> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9754

That's a dupe.

> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11366

This likely doesn't exist in 4.1.x.

> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20314

> Are all of there dups of one another?

The spec contradicts itself, basically (I'm reading Servlet 2.4 PFD 3). 
I posted messages complaining about it, and (unsurprisingly) got 
ignored. Sun spec folks are really good about ignoring people (even if 
you're a coworker) unless:
- you're on their expert group, and start complaining really loud (I'm 
not on the expert group - no time)
- you have access to the Sun Bugtraq and file a P1 bug (that one works 
so great, it's amazing :-D unfortunately, I have no access to it :-( )

There are RD requirements that would be hard to implement without 
wrapping (all those special attributes, and parameter isolation). IMO 
the parameter isolation is impossible if the request is not ours (or I 
don't know, maybe we have to extract everything before invoking the 
pipeline if a request, and then restore them one by one). So having a 
query string will make the RD dead slow (but the general case will be 
faster if we can get rid of wrapping).

Section's 6.2.2 wording is bad with respect to the new spec: the request 
dispatcher now invokes a filter pipeline, not the servlet itself.

I'm -1 for trying to change the RD behavior in TC 4.1.x (reaslistically, 
we'd break things trying to fix it, and it is clearly not worth the pain 
for the stable branch). If the spec is clarified, then we can implement 
the specified behavior in TC 5, otherwise I'd prefer keeping the current 
behavior.

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org