tomcat 5.8.0 - weird response on HTTP OPTIONS method
Is it correct that coyote reply with the home page contents on an HTTP OPTIONS method request ? Client request: OPTIONS / HTTP/1.1\r\n Request Method: OPTIONS Request URI: / Request Version: HTTP/1.1 Translate: f\r\n User-Agent: Microsoft Data Access Internet Publishing Provider Protocol Discovery\r\n Host: lan2\r\n Content-Length: 0\r\n Connection: Keep-Alive\r\n \r\n Server response: Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Request Version: HTTP/1.1 Response Code: 200 Content-Type: text/html;charset=ISO-8859-1\r\n Transfer-Encoding: chunked\r\n Date: Fri, 06 Jan 2006 10:32:07 GMT\r\n Server: Apache-Coyote/1.1\r\n \r\n HTTP chunked response SNIPPET 3e 3c 2f 74 72 3e 0d 0a 20 20 20 20 20 20 20 20 /tr.. 0010 20 20 20 20 3c 2f 74 61 62 6c 65 3e 0d 0a 20 20 /table.. 0020 20 20 20 20 20 20 3c 2f 74 64 3e 0d 0a 20 20 20 /td.. 0030 20 20 20 20 20 3c 74 64 20 61 6c 69 67 6e 3d 22td align= 0040 72 69 67 68 74 22 3e 3c 61 20 68 72 65 66 3d 22 righta href= 0050 68 74 74 70 3a 2f 2f 6a 61 6b 61 72 74 61 2e 61 http://jakarta.a 0060 70 61 63 68 65 2e 6f 72 67 2f 22 3e 3c 69 6d 67 pache.org/img 0070 20 73 72 63 3d 22 6a 61 6b 61 72 74 61 2d 62 61src=jakarta-ba 0080 6e 6e 65 72 2e 67 69 66 22 20 68 65 69 67 68 74 nner.gif height 0090 3d 22 34 38 22 20 77 69 64 74 68 3d 22 35 30 35 =48 width=505 00a0 22 20 62 6f 72 64 65 72 3d 22 30 22 20 61 6c 74border=0 alt 00b0 3d 22 54 68 65 20 4a 61 6b 61 72 74 61 20 50 72 =The Jakarta Pr 00c0 6f 6a 65 63 74 22 3e 3c 2f 61 3e 3c 2f 74 64 3e oject/a/td 00d0 0d 0a 20 20 20 20 3c 2f 74 72 3e 0d 0a 3c 2f 74 ../tr../t 00e0 61 62 6c 65 3e 0d 0a 0d 0a 3c 62 72 3e 0d 0a 0d ablebr... /SNIPPET - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat 5.8.0 - configuration problem with load balancer
Hi I am trying to load balance my tomcat server. Rule file is as below. rule className=org.apache.webapp.balancer.rules.URLStringMatchRule targetString=cadpush redirectUrl=http://10.22.11.29:8080/cadpush/servlet/CadPushEx?user=; / rule className=org.apache.webapp.balancer.rules.RequestParameterRule paramName=bearrer paramValue=sms redirectUrl=http://10.22.11.29:8080/cadpush/servlet/CadPushEx; / !-- Redirect all requests to jakarta.apache.org. -- rule className=org.apache.webapp.balancer.rules.AcceptEverythingRule redirectUrl=http://jakarta.apache.org; / when I try following request http://10.22.11.29:8080/balancer/BlahBlah?user=kunalpasswd=kunaldesti= 919879900054data=kunal parmarbearrer=sms request is going to http://10.22.11.29:8080/cadpush/servlet/CadPushEx URL but I want to read all parameter with originator URL. Like I want to read user, passwd, desti parameter in CadPushEx servlet But when tomcat is redirecting URL I am not getting any parameter of originator URL. Ho could I receive original parameter that were before redirection Regards, Kunal Parmar Hutch Gujarat. 9879900054 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat 5.8.0 - weird response on HTTP OPTIONS method
Is it correct that coyote reply with the home page contents on an HTTP OPTIONS method request ? Client request: OPTIONS / HTTP/1.1\r\n Request Method: OPTIONS Request URI: / Request Version: HTTP/1.1 Translate: f\r\n User-Agent: Microsoft Data Access Internet Publishing Provider Protocol Discovery\r\n Host: lan2\r\n Content-Length: 0\r\n Connection: Keep-Alive\r\n \r\n Server response: Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Request Version: HTTP/1.1 Response Code: 200 Content-Type: text/html;charset=ISO-8859-1\r \n Transfer-Encoding: chunked\r\n Date: Fri, 06 Jan 2006 10:32:07 GMT\r\n Server: Apache-Coyote/1.1\r\n \r\n HTTP chunked response SNIPPET 3e 3c 2f 74 72 3e 0d 0a 20 20 20 20 20 20 20 20 /tr.. 0010 20 20 20 20 3c 2f 74 61 62 6c 65 3e 0d 0a 20 20 /table.. 0020 20 20 20 20 20 20 3c 2f 74 64 3e 0d 0a 20 20 20 /td.. 0030 20 20 20 20 20 3c 74 64 20 61 6c 69 67 6e 3d 22td align= 0040 72 69 67 68 74 22 3e 3c 61 20 68 72 65 66 3d 22 righta href= 0050 68 74 74 70 3a 2f 2f 6a 61 6b 61 72 74 61 2e 61 http://jakarta.a 0060 70 61 63 68 65 2e 6f 72 67 2f 22 3e 3c 69 6d 67 pache.org/ http://pache.org/%22img 0070 20 73 72 63 3d 22 6a 61 6b 61 72 74 61 2d 62 61src=jakarta-ba 0080 6e 6e 65 72 2e 67 69 66 22 20 68 65 69 67 68 74 nner.gif height 0090 3d 22 34 38 22 20 77 69 64 74 68 3d 22 35 30 35 =48 width=505 00a0 22 20 62 6f 72 64 65 72 3d 22 30 22 20 61 6c 74border=0 alt 00b0 3d 22 54 68 65 20 4a 61 6b 61 72 74 61 20 50 72 =The Jakarta Pr 00c0 6f 6a 65 63 74 22 3e 3c 2f 61 3e 3c 2f 74 64 3e oject/a/td 00d0 0d 0a 20 20 20 20 3c 2f 74 72 3e 0d 0a 3c 2f 74 ../tr../t 00e0 61 62 6c 65 3e 0d 0a 0d 0a 3c 62 72 3e 0d 0a 0d ablebr... /SNIPPET mauro -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Mauro Bertapelle wrote: Is it correct that coyote reply with the home page contents on an HTTP OPTIONS method request ? If you post another message on this list that belongs to the user list, I'll ban you. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
oops, sorry I wasn't sure where to post it mauro -- Remy Maucherat ha scritto: Mauro Bertapelle wrote: Is it correct that coyote reply with the home page contents on an HTTP OPTIONS method request ? If you post another message on this list that belongs to the user list, I'll ban you. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Mauro Bertapelle wrote: oops, sorry I wasn't sure where to post it Ok. If you have questions about usage of Tomcat, you should post on [EMAIL PROTECTED] Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r366510 - /tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/TOMCAT_5_5_12/
Author: yoavs Date: Fri Jan 6 06:35:40 2006 New Revision: 366510 URL: http://svn.apache.org/viewcvs?rev=366510view=rev Log: Copying tag from 5.5.11 to 5.5.12 as I apparently forgot to tag 5.5.12 at the time of release. Added: tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/TOMCAT_5_5_12/ - copied from r366509, tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/TOMCAT_5_5_11/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing tag in SVN
This is done now... Thanks for pointing it out, Yoav On 1/5/06, Mark Thomas [EMAIL PROTECTED] wrote: Yoav Shapira wrote: So I guess I should just do an svn copy of servletapi from 5.5.11 to 5.5.12 to tag it as such. I don't need to do anything fancier like an svn:prop edit, right? Correct. A straight svn copy will be fine. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38012] - CGIServlet redirect
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=38012. 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=38012 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
I'm curious - why would you need the options method ? Obviously, as you found, tomcat does not support it ( and many other servers ), and I never heard of any use of it, even if it is in the spec. Well, in theory servlets could respond to 'options' method if they choose to - and so could the default servlet. Costin On 1/6/06, Mauro Bertapelle [EMAIL PROTECTED] wrote: Is it correct that coyote reply with the home page contents on an HTTP OPTIONS method request ? Client request: OPTIONS / HTTP/1.1\r\n Request Method: OPTIONS Request URI: / Request Version: HTTP/1.1 Translate: f\r\n User-Agent: Microsoft Data Access Internet Publishing Provider Protocol Discovery\r\n Host: lan2\r\n Content-Length: 0\r\n Connection: Keep-Alive\r\n \r\n Server response: Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Request Version: HTTP/1.1 Response Code: 200 Content-Type: text/html;charset=ISO-8859-1\r \n Transfer-Encoding: chunked\r\n Date: Fri, 06 Jan 2006 10:32:07 GMT\r\n Server: Apache-Coyote/1.1\r\n \r\n HTTP chunked response SNIPPET 3e 3c 2f 74 72 3e 0d 0a 20 20 20 20 20 20 20 20 /tr.. 0010 20 20 20 20 3c 2f 74 61 62 6c 65 3e 0d 0a 20 20 /table.. 0020 20 20 20 20 20 20 3c 2f 74 64 3e 0d 0a 20 20 20 /td.. 0030 20 20 20 20 20 3c 74 64 20 61 6c 69 67 6e 3d 22td align= 0040 72 69 67 68 74 22 3e 3c 61 20 68 72 65 66 3d 22 righta href= 0050 68 74 74 70 3a 2f 2f 6a 61 6b 61 72 74 61 2e 61 http://jakarta.a 0060 70 61 63 68 65 2e 6f 72 67 2f 22 3e 3c 69 6d 67 pache.org/ http://pache.org/%22img 0070 20 73 72 63 3d 22 6a 61 6b 61 72 74 61 2d 62 61src=jakarta-ba 0080 6e 6e 65 72 2e 67 69 66 22 20 68 65 69 67 68 74 nner.gif height 0090 3d 22 34 38 22 20 77 69 64 74 68 3d 22 35 30 35 =48 width=505 00a0 22 20 62 6f 72 64 65 72 3d 22 30 22 20 61 6c 74border=0 alt 00b0 3d 22 54 68 65 20 4a 61 6b 61 72 74 61 20 50 72 =The Jakarta Pr 00c0 6f 6a 65 63 74 22 3e 3c 2f 61 3e 3c 2f 74 64 3e oject/a/td 00d0 0d 0a 20 20 20 20 3c 2f 74 72 3e 0d 0a 3c 2f 74 ../tr../t 00e0 61 62 6c 65 3e 0d 0a 0d 0a 3c 62 72 3e 0d 0a 0d ablebr... /SNIPPET mauro -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EL and JSP 2.1
On 12/27/05, Mark Thomas [EMAIL PROTECTED] wrote: My own views in line. Mark Mark Thomas wrote: Jacob Hookom wrote: I'd like to get the ball rolling on a branch for JSP 2.1. I can get the SVN stuff set up over the next few days. There has been some debate about how we arrange things so we need to get agreement on the way forward. The key questions are: - does 6.0.x become the main development branch? Yes. We did this for 5.5.x and it worked. Yes, you'll need to create a branch for 5.5. - do we merge jasper and container? No. Good to keep them independent. The independence is not given by the fact they are in different trees - the connector and container are not independent, yet in different trees. And the 'separation' of jasper and container can be achieved as well by continuing to use differet packages :-). - do we merge build and container Maybe. If someone wants to take the time to do this and update the build scripts great. Personally, not an itch I feel the need to scratch. Probably doesn't make sense if this is the only change. It seems people are not ok with a single source tree. - do we maintain servletapi for 6.0? No for the api stuff proper. We don't host it, can't change it and our own implementation would be more trouble than it is worth. Maybe for the examples. It is useful to be able to fix problems with them. The examples could always be merged in with the container module. IMO - 6.0 would be the best chance to reorg the tree structure. Given that JDK1.5 will be required, it means we could remove all 1.4 code and hacks, and a lot of the build hacks that are used to deal with multiple VMs and options. I think we should just create a tomcat6/ repository, and then take a snapshot of all subtrees in the current tomcat and place the all in the same tree, under tomcat6/java. Then start with a fresh build.xml - excluding or removing the 1.1 - 1.4 support classes. Well - I would go even further, on creating a smaller number of jars for the distribution, but I guess that would be even less popular than the singe tree. I do understand I'm in a very small minority with this proposal, just want to have it on the record :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38167] New: - tomcat 5.0.30 hangs at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:215)
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=38167.
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=38167
Summary: tomcat 5.0.30 hangs at
sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:215)
Product: Tomcat 5
Version: 5.0.9
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Connector:Coyote
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
On a heavily loaded server tomcat 5.0.30 sometimes hangs. I observed in the the
threads trace that almost all threads hanging like this:
TP-Processor296 daemon prio=1 tid=0x081fbe28 nid=0x13a5 waiting on condition
[0x7720b000..0x7720b658]
at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:215)
at
java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2006)
at
java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1971)
at java.util.Calendar.setTimeInMillis(Calendar.java:1066)
at java.util.GregorianCalendar.init(GregorianCalendar.java:576)
at java.util.Calendar.createCalendar(Calendar.java:968)
at java.util.Calendar.getInstance(Calendar.java:954)
at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:503)
at java.text.SimpleDateFormat.init(SimpleDateFormat.java:446)
at
org.apache.coyote.tomcat5.CoyoteRequest.init(CoyoteRequest.java:152)
at
org.apache.coyote.tomcat5.CoyoteConnector.createRequest(CoyoteConnector.java:1230)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:131)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
I don't know why this happens, but a quick look at the source seems to reveal
that
protected SimpleDateFormat formats[] = {
new SimpleDateFormat(EEE, dd MMM HH:mm:ss zzz, Locale.US),
new SimpleDateFormat(EE, dd-MMM-yy HH:mm:ss zzz, Locale.US),
new SimpleDateFormat(EEE d HH:mm:ss , Locale.US)
};
isn't used any longer in getDateHeader(), because that method uses
FastHttpDateFormat which has its own formats[].
If that's the case, could you please fix it and release an update?
--
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]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Costin, I'm tweaking with internet explorer and his web folder feature (access to webdav resource). When accessing a webdav resource, ie fire a lot of OPTIONS requests, not only to the specified url but as you see from my example even to the / uri which is obviously catched by the default servlet and not by the webdav servlet. Mauro -- Costin Manolache wrote: I'm curious - why would you need the options method ? Obviously, as you found, tomcat does not support it ( and many other servers ), and I never heard of any use of it, even if it is in the spec. Well, in theory servlets could respond to 'options' method if they choose to - and so could the default servlet. Costin On 1/6/06, Mauro Bertapelle [EMAIL PROTECTED] wrote: Is it correct that coyote reply with the home page contents on an HTTP OPTIONS method request ? Client request: OPTIONS / HTTP/1.1\r\n Request Method: OPTIONS Request URI: / Request Version: HTTP/1.1 Translate: f\r\n User-Agent: Microsoft Data Access Internet Publishing Provider Protocol Discovery\r\n Host: lan2\r\n Content-Length: 0\r\n Connection: Keep-Alive\r\n \r\n Server response: Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Request Version: HTTP/1.1 Response Code: 200 Content-Type: text/html;charset=ISO-8859-1\r \n Transfer-Encoding: chunked\r\n Date: Fri, 06 Jan 2006 10:32:07 GMT\r\n Server: Apache-Coyote/1.1\r\n \r\n HTTP chunked response SNIPPET 3e 3c 2f 74 72 3e 0d 0a 20 20 20 20 20 20 20 20 /tr.. 0010 20 20 20 20 3c 2f 74 61 62 6c 65 3e 0d 0a 20 20 /table.. 0020 20 20 20 20 20 20 3c 2f 74 64 3e 0d 0a 20 20 20 /td.. 0030 20 20 20 20 20 3c 74 64 20 61 6c 69 67 6e 3d 22td align= 0040 72 69 67 68 74 22 3e 3c 61 20 68 72 65 66 3d 22 righta href= 0050 68 74 74 70 3a 2f 2f 6a 61 6b 61 72 74 61 2e 61 http://jakarta.a 0060 70 61 63 68 65 2e 6f 72 67 2f 22 3e 3c 69 6d 67 pache.org/ http://pache.org/%22img 0070 20 73 72 63 3d 22 6a 61 6b 61 72 74 61 2d 62 61src=jakarta-ba 0080 6e 6e 65 72 2e 67 69 66 22 20 68 65 69 67 68 74 nner.gif height 0090 3d 22 34 38 22 20 77 69 64 74 68 3d 22 35 30 35 =48 width=505 00a0 22 20 62 6f 72 64 65 72 3d 22 30 22 20 61 6c 74border=0 alt 00b0 3d 22 54 68 65 20 4a 61 6b 61 72 74 61 20 50 72 =The Jakarta Pr 00c0 6f 6a 65 63 74 22 3e 3c 2f 61 3e 3c 2f 74 64 3e oject/a/td 00d0 0d 0a 20 20 20 20 3c 2f 74 72 3e 0d 0a 3c 2f 74 ../tr../t 00e0 61 62 6c 65 3e 0d 0a 0d 0a 3c 62 72 3e 0d 0a 0d ablebr... /SNIPPET mauro -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Facing problem when 2 simultaneous requests are sent to tomcat.
This belongs on the users list. Please read http://tomcat.apache.org/lists.html Mark [EMAIL PROTECTED] Uttam wrote: Hi All, I am a newbei using the Tomcat server in my application. *Sorry all, I gave a wrong information*. I am using *Apache Tomcat 5.512* server and not 5.0.28. JDK 1.5 Update 5 JRE 5 Update 6 I want simultaneous php files to executed for my project. So for testing purposes, I have written a simple file test PHP file which does this - 1. As soon it is called, it prints a debug message (Request received message) on the IE window. 2. Sleeps for 5 sec. 3. After sleep, prints on more debug message on the IE window and quits. When I call this test PHP file simultaneously from two separate Internet Explorer windows, I face this strange problem - The first message (Request received message) will be printed in both the windows. Then the second message for both the windows will be printed in the last window i.e. which ever page was submitted later. I am attaching the web.xml and server.xml files along with the mail. Somebody please help me... Thanks in advance. Regards, Uttam. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Interesting. Well, Remy is the expert in webdav, but I guess you'll need to talk with him on the users list :-) I suppose the default servlet could handle 'options', since it's part of the standard, but for regular servlets there is nothing to be done, it's up to them to implement whatever methods they want. Costin On 1/6/06, Mauro Bertapelle [EMAIL PROTECTED] wrote: Costin, I'm tweaking with internet explorer and his web folder feature (access to webdav resource). When accessing a webdav resource, ie fire a lot of OPTIONS requests, not only to the specified url but as you see from my example even to the / uri which is obviously catched by the default servlet and not by the webdav servlet. Mauro -- Costin Manolache wrote: I'm curious - why would you need the options method ? Obviously, as you found, tomcat does not support it ( and many other servers ), and I never heard of any use of it, even if it is in the spec. Well, in theory servlets could respond to 'options' method if they choose to - and so could the default servlet. Costin On 1/6/06, Mauro Bertapelle [EMAIL PROTECTED] wrote: Is it correct that coyote reply with the home page contents on an HTTP OPTIONS method request ? Client request: OPTIONS / HTTP/1.1\r\n Request Method: OPTIONS Request URI: / Request Version: HTTP/1.1 Translate: f\r\n User-Agent: Microsoft Data Access Internet Publishing Provider Protocol Discovery\r\n Host: lan2\r\n Content-Length: 0\r\n Connection: Keep-Alive\r\n \r\n Server response: Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Request Version: HTTP/1.1 Response Code: 200 Content-Type: text/html;charset=ISO-8859-1\r \n Transfer-Encoding: chunked\r\n Date: Fri, 06 Jan 2006 10:32:07 GMT\r\n Server: Apache-Coyote/1.1\r\n \r\n HTTP chunked response SNIPPET 3e 3c 2f 74 72 3e 0d 0a 20 20 20 20 20 20 20 20 /tr.. 0010 20 20 20 20 3c 2f 74 61 62 6c 65 3e 0d 0a 20 20 /table.. 0020 20 20 20 20 20 20 3c 2f 74 64 3e 0d 0a 20 20 20 /td.. 0030 20 20 20 20 20 3c 74 64 20 61 6c 69 67 6e 3d 22td align= 0040 72 69 67 68 74 22 3e 3c 61 20 68 72 65 66 3d 22 righta href= 0050 68 74 74 70 3a 2f 2f 6a 61 6b 61 72 74 61 2e 61 http://jakarta.a 0060 70 61 63 68 65 2e 6f 72 67 2f 22 3e 3c 69 6d 67 pache.org/ http://pache.org/%22img 0070 20 73 72 63 3d 22 6a 61 6b 61 72 74 61 2d 62 61src=jakarta-ba 0080 6e 6e 65 72 2e 67 69 66 22 20 68 65 69 67 68 74 nner.gif height 0090 3d 22 34 38 22 20 77 69 64 74 68 3d 22 35 30 35 =48 width=505 00a0 22 20 62 6f 72 64 65 72 3d 22 30 22 20 61 6c 74border=0 alt 00b0 3d 22 54 68 65 20 4a 61 6b 61 72 74 61 20 50 72 =The Jakarta Pr 00c0 6f 6a 65 63 74 22 3e 3c 2f 61 3e 3c 2f 74 64 3e oject/a/td 00d0 0d 0a 20 20 20 20 3c 2f 74 72 3e 0d 0a 3c 2f 74 ../tr../t 00e0 61 62 6c 65 3e 0d 0a 0d 0a 3c 62 72 3e 0d 0a 0d ablebr... /SNIPPET mauro -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EL and JSP 2.1
Hi, I'm actually +1 to more or less everything Costin said ;) Yoav On 1/6/06, Costin Manolache [EMAIL PROTECTED] wrote: On 12/27/05, Mark Thomas [EMAIL PROTECTED] wrote: My own views in line. Mark Mark Thomas wrote: Jacob Hookom wrote: I'd like to get the ball rolling on a branch for JSP 2.1. I can get the SVN stuff set up over the next few days. There has been some debate about how we arrange things so we need to get agreement on the way forward. The key questions are: - does 6.0.x become the main development branch? Yes. We did this for 5.5.x and it worked. Yes, you'll need to create a branch for 5.5. - do we merge jasper and container? No. Good to keep them independent. The independence is not given by the fact they are in different trees - the connector and container are not independent, yet in different trees. And the 'separation' of jasper and container can be achieved as well by continuing to use differet packages :-). - do we merge build and container Maybe. If someone wants to take the time to do this and update the build scripts great. Personally, not an itch I feel the need to scratch. Probably doesn't make sense if this is the only change. It seems people are not ok with a single source tree. - do we maintain servletapi for 6.0? No for the api stuff proper. We don't host it, can't change it and our own implementation would be more trouble than it is worth. Maybe for the examples. It is useful to be able to fix problems with them. The examples could always be merged in with the container module. IMO - 6.0 would be the best chance to reorg the tree structure. Given that JDK1.5 will be required, it means we could remove all 1.4 code and hacks, and a lot of the build hacks that are used to deal with multiple VMs and options. I think we should just create a tomcat6/ repository, and then take a snapshot of all subtrees in the current tomcat and place the all in the same tree, under tomcat6/java. Then start with a fresh build.xml - excluding or removing the 1.1 - 1.4 support classes. Well - I would go even further, on creating a smaller number of jars for the distribution, but I guess that would be even less popular than the singe tree. I do understand I'm in a very small minority with this proposal, just want to have it on the record :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Tomcat handles it just fine -- if you implement it in your servlet :-) Options conveys not only whether a resource is dav-enabled and the class of dav support, but it has a well-defined xml response body for a number of ACL and DeltaV properties, all of which needs to be handled by the application, not tomcat. You are going to have to override it anyway to specify the DAV: header, at a minimum. Tomcat can't know whether your application supports dav locking or not, for instance. Keith Costin Manolache wrote: Interesting. Well, Remy is the expert in webdav, but I guess you'll need to talk with him on the users list :-) I suppose the default servlet could handle 'options', since it's part of the standard, but for regular servlets there is nothing to be done, it's up to them to implement whatever methods they want. Costin On 1/6/06, Mauro Bertapelle [EMAIL PROTECTED] wrote: Costin, I'm tweaking with internet explorer and his web folder feature (access to webdav resource). When accessing a webdav resource, ie fire a lot of OPTIONS requests, not only to the specified url but as you see from my example even to the / uri which is obviously catched by the default servlet and not by the webdav servlet. Mauro -- Costin Manolache wrote: I'm curious - why would you need the options method ? Obviously, as you found, tomcat does not support it ( and many other servers ), and I never heard of any use of it, even if it is in the spec. Well, in theory servlets could respond to 'options' method if they choose to - and so could the default servlet. Costin On 1/6/06, Mauro Bertapelle [EMAIL PROTECTED] wrote: Is it correct that coyote reply with the home page contents on an HTTP OPTIONS method request ? Client request: OPTIONS / HTTP/1.1\r\n Request Method: OPTIONS Request URI: / Request Version: HTTP/1.1 Translate: f\r\n User-Agent: Microsoft Data Access Internet Publishing Provider Protocol Discovery\r\n Host: lan2\r\n Content-Length: 0\r\n Connection: Keep-Alive\r\n \r\n Server response: Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Request Version: HTTP/1.1 Response Code: 200 Content-Type: text/html;charset=ISO-8859-1\r \n Transfer-Encoding: chunked\r\n Date: Fri, 06 Jan 2006 10:32:07 GMT\r\n Server: Apache-Coyote/1.1\r\n \r\n HTTP chunked response SNIPPET 3e 3c 2f 74 72 3e 0d 0a 20 20 20 20 20 20 20 20 /tr.. 0010 20 20 20 20 3c 2f 74 61 62 6c 65 3e 0d 0a 20 20 /table.. 0020 20 20 20 20 20 20 3c 2f 74 64 3e 0d 0a 20 20 20 /td.. 0030 20 20 20 20 20 3c 74 64 20 61 6c 69 67 6e 3d 22td align= 0040 72 69 67 68 74 22 3e 3c 61 20 68 72 65 66 3d 22 righta href= 0050 68 74 74 70 3a 2f 2f 6a 61 6b 61 72 74 61 2e 61 http://jakarta.a 0060 70 61 63 68 65 2e 6f 72 67 2f 22 3e 3c 69 6d 67 pache.org/ http://pache.org/%22img 0070 20 73 72 63 3d 22 6a 61 6b 61 72 74 61 2d 62 61src=jakarta-ba 0080 6e 6e 65 72 2e 67 69 66 22 20 68 65 69 67 68 74 nner.gif height 0090 3d 22 34 38 22 20 77 69 64 74 68 3d 22 35 30 35 =48 width=505 00a0 22 20 62 6f 72 64 65 72 3d 22 30 22 20 61 6c 74border=0 alt 00b0 3d 22 54 68 65 20 4a 61 6b 61 72 74 61 20 50 72 =The Jakarta Pr 00c0 6f 6a 65 63 74 22 3e 3c 2f 61 3e 3c 2f 74 64 3e oject/a/td 00d0 0d 0a 20 20 20 20 3c 2f 74 72 3e 0d 0a 3c 2f 74 ../tr../t 00e0 61 62 6c 65 3e 0d 0a 0d 0a 3c 62 72 3e 0d 0a 0d ablebr... /SNIPPET mauro -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
I guess the problem was that the default servlet ( part of tomcat ) doesn't handle options for static files like /, instead returns the page as if it would be a GET. I tried on www.apache.org - and apache seems to return the right thing ( no body, etc ). Costin On 1/6/06, Keith Wannamaker [EMAIL PROTECTED] wrote: Tomcat handles it just fine -- if you implement it in your servlet :-) Options conveys not only whether a resource is dav-enabled and the class of dav support, but it has a well-defined xml response body for a number of ACL and DeltaV properties, all of which needs to be handled by the application, not tomcat. You are going to have to override it anyway to specify the DAV: header, at a minimum. Tomcat can't know whether your application supports dav locking or not, for instance. Keith Costin Manolache wrote: Interesting. Well, Remy is the expert in webdav, but I guess you'll need to talk with him on the users list :-) I suppose the default servlet could handle 'options', since it's part of the standard, but for regular servlets there is nothing to be done, it's up to them to implement whatever methods they want. Costin On 1/6/06, Mauro Bertapelle [EMAIL PROTECTED] wrote: Costin, I'm tweaking with internet explorer and his web folder feature (access to webdav resource). When accessing a webdav resource, ie fire a lot of OPTIONS requests, not only to the specified url but as you see from my example even to the / uri which is obviously catched by the default servlet and not by the webdav servlet. Mauro -- Costin Manolache wrote: I'm curious - why would you need the options method ? Obviously, as you found, tomcat does not support it ( and many other servers ), and I never heard of any use of it, even if it is in the spec. Well, in theory servlets could respond to 'options' method if they choose to - and so could the default servlet. Costin On 1/6/06, Mauro Bertapelle [EMAIL PROTECTED] wrote: Is it correct that coyote reply with the home page contents on an HTTP OPTIONS method request ? Client request: OPTIONS / HTTP/1.1\r\n Request Method: OPTIONS Request URI: / Request Version: HTTP/1.1 Translate: f\r\n User-Agent: Microsoft Data Access Internet Publishing Provider Protocol Discovery\r\n Host: lan2\r\n Content-Length: 0\r\n Connection: Keep-Alive\r\n \r\n Server response: Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Request Version: HTTP/1.1 Response Code: 200 Content-Type: text/html;charset=ISO-8859-1\r \n Transfer-Encoding: chunked\r\n Date: Fri, 06 Jan 2006 10:32:07 GMT\r\n Server: Apache-Coyote/1.1\r\n \r\n HTTP chunked response SNIPPET 3e 3c 2f 74 72 3e 0d 0a 20 20 20 20 20 20 20 20 /tr.. 0010 20 20 20 20 3c 2f 74 61 62 6c 65 3e 0d 0a 20 20 /table.. 0020 20 20 20 20 20 20 3c 2f 74 64 3e 0d 0a 20 20 20 /td.. 0030 20 20 20 20 20 3c 74 64 20 61 6c 69 67 6e 3d 22td align= 0040 72 69 67 68 74 22 3e 3c 61 20 68 72 65 66 3d 22 righta href= 0050 68 74 74 70 3a 2f 2f 6a 61 6b 61 72 74 61 2e 61 http://jakarta.a 0060 70 61 63 68 65 2e 6f 72 67 2f 22 3e 3c 69 6d 67 pache.org/ http://pache.org/%22img 0070 20 73 72 63 3d 22 6a 61 6b 61 72 74 61 2d 62 61src=jakarta-ba 0080 6e 6e 65 72 2e 67 69 66 22 20 68 65 69 67 68 74 nner.gif height 0090 3d 22 34 38 22 20 77 69 64 74 68 3d 22 35 30 35 =48 width=505 00a0 22 20 62 6f 72 64 65 72 3d 22 30 22 20 61 6c 74border=0 alt 00b0 3d 22 54 68 65 20 4a 61 6b 61 72 74 61 20 50 72 =The Jakarta Pr 00c0 6f 6a 65 63 74 22 3e 3c 2f 61 3e 3c 2f 74 64 3e oject/a/td 00d0 0d 0a 20 20 20 20 3c 2f 74 72 3e 0d 0a 3c 2f 74 ../tr../t 00e0 61 62 6c 65 3e 0d 0a 0d 0a 3c 62 72 3e 0d 0a 0d ablebr... /SNIPPET mauro -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Costin, you've got the point I was trying to make, this has nothing to do with webdav and the naive way in which ie implements it, but probably Tomcat should handle options better when it's acting as a static web server. Mauro -- Costin Manolache wrote: I guess the problem was that the default servlet ( part of tomcat ) doesn't handle options for static files like /, instead returns the page as if it would be a GET. I tried on www.apache.org - and apache seems to return the right thing ( no body, etc ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
