Re: HttpServletResponse.setContentLength() method in Tomcat 5.5.9
Ahab Abouzour wrote: Hello all, My servlet stopped working when I moved from Tomcat4.0.6 to Tomcat5.5.9. After investigating the problem, it turns out that if the HttpServletResponse.setContentLength() method is called, subsequent calls (e.g. setHeader(), addHeader(),addCookie()..etc) into the HttpServletResponse object are completely ignored (or discarded from underneath!). For example, if I do the following in my service method: (httpResponse is defined HttpServletResponse) httpResopnse.setStatus(204); // I tried 200 and got the same problem, I guess status code doesn't play part in this problem. httpResponse.setHeader(header1,value1); //works httpResponse.setHeader(header2,value2); //works httpResponse.setContentLength(0); // nothing gets set on the response object after this point httpResponse.setHeader(header3,value3); // ignored! httpResponse.addCookie(new Cookie(JSESSIONID,myCookie)); // ignored! My proxy shows that header1 and header2 are set correctly but header3 and my cookie are missing! It seems that it expects setContentLength is the last method to be set on the response object and any method call after that on the resopnse object gets ignored (or discarded) I have attached a simple servlet that reproduces this problem. My question: is this an expected behaviour? I checked the http specs and the servlet 2.4 specs but nothing specified this behaviour. Can someone please explain if this is the expected behaviour (and why? specs..etc) or it's a bug? Thanks in advance, Known problem, supposed to be fixed: http://issues.eu.apache.org/bugzilla/show_bug.cgi?id=32604 Best regards, Julian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Expect: 100-continue
Hi, Looking at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4812000: -- DESCRIPTION OF THE PROBLEM : The servlet API provides no means of controlling the 100- continue response when the user agent expects it, and doesn't specify when it is or is not sent by the servlet container. It should do so. One suggestion to handle this would be: 1. Add a method to HttpServletRequest called acceptRequest or some such, which causes a 100-continue to be sent. acceptRequest would have no effect if the user agent doesn't expect a 100-continue. 2. Specify that 100-continue will not be sent until one of the following happens to the request object: a. acceptRequest() is called b. getInputStream() or getReader() is called c. For the POST method, getParameter() or similar is called. This would be compatible with the current specification (though not with current tomcat, which always sends 100- continue immediately), but provide the ability for better control. -- Does Tomcat5 (or 4, for that matter) actually implement one of these options (2bc, for instance)? Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Byte-Range-Serving of DefaultServlet and Acrobat 6
Remy Maucherat wrote: ... 2. blanks in multi-byte-range-requests After having added the header above, Acrobat sent byte-range-requests. But Acrobat choked. I did a packet filtering and recognized the following status code sent by Tomcat 416 request range not satisfiable. The reason was that Acrobat sent multi-byte-range-request using e.g. the following string 1000-2000, 3000-3010 Notice the blank character. It leads to a parsing exception in line 1300 of the DefaultServlet (Tomcat 4.1.30). If you do a trim() on the rangeDefinition obtained there, this error does not occur. Please prove using the HTTP spec that it has to be done that way. I think that's pretty clear from http://greenbytes.de/tech/webdav/rfc2616.html#header.range and http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.1. ... Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27100] - WebDAV locking implementation incompatible with some clients.
[EMAIL PROTECTED] wrote: I think the problem is that the servlet obsfucates lock tokens, which it has every right to do (this is from memory). That's incorrect. It has the right to *hide* lock tokens, but not to return incorrect ones. Anyway, the servlet supports WebDAV level 1, which doesn't include locking (which is very complex to implement completely, so is only partially implemented). I'll let Mark resolve this report. Can anybody explain why the servlet actually *intends* to hide the lock token? Each and every WebDAV server I've seen (and I've seen a lot) reveals them upon PROPFFIND/lockdiscovery. Regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WebDAV and TC5
Jess Holle wrote: WebDAV seems to be largely an empty promise due to the lack of reasonable, compatible clients. 90% of all clients are Microsoft Windows. Microsoft Windows' Web Folders support WebDAV to a *small* degree. Yet the way this is integrated into the OS is at such a level that 99% of all Windows apps are incompatible in full or part with Web Folders (e.g. you can't directly save to or open from web folders from these apps). Even Microsoft Office is only compatible with web folders in the most common menu items (e.g. open/save) whereas various other file dialogs for importing, object inclusion, etc, are not compatible with web folders. The kicker for app developers: the OS does not give you a normal file path (or File object in Java) for objects in web folders -- thus requiring special action to be compatible. I've tried products which claim to give the level of integration that Microsoft failed to achieve. Unfortunately, they proved unstable and unreliable. Now various UNIX flavors may well provide file system mappings to WebDAV (and the OS X one sounds nice), but unfortunately for those who produce servers that would like to be able to just expose themselves to clients via WebDAV this is essentially useless for 90% of the market. I absolutely disagree. Windows comes with two clients (an explorer extension and a filesystem driver), MacOSX comes with a drriver, and there's also a Linux FS. Many major applications (for instance Adobe or OpenOffice) support it as well. WebDAV is robust and interoperability is actually quite good. Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WebDAV and TC5
Jess Holle wrote: How does the user use the filesystem driver? net use ... The end-user certainly cannot achieve anything meaningful via web folders. I did a lot of testing in this regard. Well, I disagree. Lots of my customers use webfolders heavily. Now if there is a better level of usability/functionality achievable with Windows without significant additional client side programming, I'd love to hear more about it -- i.e. I'd love to discover I'm simply ignorant here and find a silver bullet for this issue! Of course there isn't any silver bullet. But all clients I've seen are still better than non-programmatic access or FTP. OpenOffice is very small in terms of market share, though I certainly wish it all the best! Adobe is also fairly small in terms of market share. Oh well. Microsoft Office is not small in market share, and works very well with WebDAV. What is really necessary is an across-the-board file-system and desktop GUI level integration such that all applications on the OS get some level of functionality with WebDAV (including open and save as a minimum!) and those that are DAV-aware may get more. App-by-app DAV awareness is *much* less interesting as it is guaranteed to be inconsistent between apps and as a server-vendor one can't depend on it being present in the client apps. I've not seen any means to achieve this across-the-board functionality with Windows (and again, *please* prove me ignorant here). Well, use one of the many filesystem drivers (Xythos, Windows XP, ...). Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer: Mark Thomas
Remy Maucherat wrote: Hi, I'd like to nominate Mark Thomas as a Tomcat committer. He has contibuted a significant amount of fixes already, and does what nobody else does: roam Bugzila to fix older issues and cleanup the database. He has special interest in the WebDAV code, which currently has no maintainer. He has my +1. I can't vote (not being an active community member except for reporting bugs), but I certainly agree (just a few seconds ago I thanked him for working on the DAV issues). Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
