You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2007/02/17 15:14:16 UTC
DO NOT REPLY [Bug 41651] New: - SC_NOT_MODIFIED should not occur on secure sessions
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=41651>.
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=41651
Summary: SC_NOT_MODIFIED should not occur on secure sessions
Product: Tomcat 5
Version: Unknown
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Servlets:WebDAV
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: m4341@abc.se
SC_NOT_MODIFIED assumes that a cached instance of an object is present, but
documents served over a secure connection shouldn't be cached. There are also
other cases where the SC_NOT_MODIFIED status shouldn't be returned, but for
simplicity I leave these out for now:
Assuming that a secure HTTP connection is used, and that the user is
authenticated by Basic authentication with read access (operations GET,
PROPFIND, OPTIONS, LOCK and UNLOCK are permitted)
A specific problem occurs when using Microsoft Word to access a WebDAV stored
document over https as follows:
1. Open the document from the server.
2. Edit the document.
3. Try to save the document, but the permissions doesn't allow saving so the
save fails with an error message in Word. (but Word writes the document to the
web cache, (fault 1))
4. Close MS Word.
5. Open the document from MS Word again. What happens now is that word first
looks into the local cache and discovers the document that was written there
during the attempted save and therefore does a request with the header field
"if-none-match" over the secure connection. (fault 2) Then the server is
validating that header field and returns a 304 (SC_NOT_MODIFIED) instead of
ignoring the "if-none-match" data (fault2) and send the file.
This is mostly a problem with MS WebDAV, but if the SC_NOT_MODIFIED isn't sent
for the following cases the problem should be reduced:
1. No SC_NOT_MODIFIED for secure HTTP connections.
2. If it's possible to verify that no caching shall occur the SC_NOT_MODIFIED
shouldn't be sent either. (this case may be a real problem)
One way around that I have attempted at first was to implement a filter, but
there is no easy way (that I have found) to filter certain headers from a
HttpServletRequest. If the headers could be manipulated in a filter that would
actually be an easy way around the problem. i.e.
setHeader()/removeHeader()-methods for the HttpServletRequest (or superclass).
The problem with this condition is that it may be the cause for confusion since
documents may appear different on one client compared to another client while
accessing the same source. From my point of view it's mostly a Microsoft
problem, but this doesn't say that it can't occur with other applications as well.
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 41651] - SC_NOT_MODIFIED should not occur on secure sessions
Posted by bu...@apache.org.
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=41651>.
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=41651
markt@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From markt@apache.org 2007-02-25 19:46 -------
Reading through this report I see one potential Tomcat issue, making use of the
if-none-match header and returning a 304 if the request is over HTTPS. However,
I can't find any relevant specification that states Tomcat must (or even should)
ignore an if-none-match header when the request is over HTTPS. I am therefore
resolving this report as INVALID.
If you are aware of part of a specification I have overlooked, please feel free
to re-open this report and provide a reference to that specification.
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org