DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=41017>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41017 ------- Additional Comments From [EMAIL PROTECTED] 2006-11-22 09:04 ------- (You assume I reopen bugs for no good reason, but from my p.o.v, you seem to be closing them for no good reason. Thanks for keeping an open mind.) ----javadoc----- public void setHeader(String name, String value) Sets a response header with the given name and value. If the header had already been set, the new value overwrites the previous one. The containsHeader method can be used to test for the presence of a header before setting its value. ----spec SRV5.2 headers-------- The setHeader method sets a header with a given name and value. A previous header is replaced by the new header. Where a set of header values exist for the name, the values are cleared and replaced with the new value. ---------------- Subjectively speaking, there is no unsetHeader() and you can imagine that the JSR wouldn't have forgotten about that. The .reset() is the only way to clear headers. The behavior of setHeader(name, null) on a non-existing header is to actually add an entry in the headers with a null value. This indicates the tomcat code can at least support null values. Therefore, replacement of an existing value with null is supported. Otherwise, it remains impossible to clear just one: since you cannot find existing headers names nor values, you cannot back them up prior to reset and cannot repopulate the existing headers you want to keep (ex: from a servlet filter in orthogonal code). So, the api subjectively indicates that clearing a header is done through setHeader(null) although not declaratively spec'ed out. in the jsr. I know it is weak. ------- There is no workaround in the mean time, except fiddling with the server.xml <Valve className="org.apache.catalina.authenticator.FormAuthenticator" securePagesWithPragma="false" disableProxyCaching="false"/> which brings its own problems of course, like revising the entire cache headers production layer of an app, with all the caching regression tests for the frackin' browsers...(sigh) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
