Re: Deny Put Delete
On 1/25/2014 9:32 PM, Vicky B wrote: if I have a privilege to ask a question on this topic if can anyone help me on how an user fire a put request or delete request ( I am not a hacker) .All my life I just used post and get I never thought about these put and delete, so if someone helps I would appreciate On Fri, Jan 24, 2014 at 4:29 PM, Johan Compagner jcompag...@servoy.comwrote: I've dealt with similar nonsensical compliance scans before, and my response was: You believe you can PUT or DELETE files on this installation? ** makes popcorn ** Please proceed. I'll sit here and watch. Take your time. Morons. Bane of productive peoples' existence. Also, a special place in hell for the writers of these scanners... /rant -- Maybe even more stupid with this scanner could be that it only test for the options request to see what it returns but does not do an actual test of it really works? Maybe i can have a server that only replies that it accepts a GET but when i actually do fire a PUT or a DELETE the code does do something... johan 1. install curl 2. man curl Curl exists for Windows as well. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Deny Put Delete
On Sun, Jan 26, 2014 at 12:32 AM, Vicky B vickyb2...@gmail.com wrote: if I have a privilege to ask a question on this topic if can anyone help me on how an user fire a put request or delete request ( I am not a hacker) .All my life I just used post and get I never thought about these put and delete, so if someone helps I would appreciate PUT and DELETE type of requests are regularly used in RESTful applications. So, any REST client would be able to send these type of requests, e.g. POSTER extension for Firefox, POSTMAN extension for Chrome, etc... Also, Mark mentioned CURL command line URL client, e.g. curl -X DELETE http://www.somewebsite.here/page curl -X PUT http://www.somewebsite.here/page Good luck! Neven
Re: Tomcat 7.0.50 tldValidation
2014-01-24 Konstantin Kolinko knst.koli...@gmail.com:
2014/1/24 Mark Thomas ma...@apache.org:
On 23/01/2014 15:25, Christopher Schultz wrote:
On 1/23/14, 10:17 AM, Mark Thomas wrote:
On 23/01/2014 15:11, Christopher Schultz wrote:
If that's true, then the Digester should be using the public
namespace id of the schema and ignoring the (incomplete) URL
provided by the XML document in order to locate the Schema in
the local catalog. (I inadvertently said system id in my
previous message, but I meant public namespace id... that is,
http://java.sun.com/xml/ns/j2ee;).
There are a couple of difficulties with that.
1. The namespace does not identify a single schema - it is associated
with several.
2. The namespace is not available to the EntityResolver.
Given the XML document in the original post, what is causing
Tomcat /not/ to load that local XML Schema?
The way the new custom resolver is written. As per my original
response, we could look at better handling for this case. I'd
need to go back to the archives and research if there is a reason
for the current behaviour.
Okay. Having written a few custom resolvers for just this purpose,
I recall them being a total PITA to get right.
The resolver only has the incomplete location
web-jsptaglibrary_2_0.xsd to work with. Such a location is normally
resolved as relative to the location of the document using it. Since
the document containing this reference is a TLD in a web app, that
isn't going to work unless the schemas are located alongside the TLDs.
Given that later versions of the standard tag libraries use an
absolute location of
http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd; (which
Tomcat recognises and directs the parser to its local copy) I'm minded
to view this as an implementation bug in that tag library that can be
worked around by disabling TLD validation.
We could take the view that if we see a location of
web-jsptaglibrary_2_0.xsd (or any other schema name in the j2ee
namespace) we can assume it is a j2ee schema and resolve it as such.
As long as this is a fall-back position (i.e. the relative to current
resource location is checked first) then I don't think there is any
risk associated with it.
We could add web-jsptaglibrary_2_0.xsd to our lookup table (like we
do when calling DigesterFactory.addSelf())
Specification:
http://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation
http://www.w3.org/TR/xmlschema-1/#schema-loc
Personally, I feel safer to use our local copy of the schema over one
loaded from elsewhere.
I suspect that if needed our schemas can be overwritten by placing
unpacked resources into ${catalina.base}/lib.
AFAIR from debugging, loading a schema for web.xml involves loading a
dozen of xsd resources. This loading is repeated for each
web-fragment.xml. I wonder whether such Schema objects could be
cached.
(Given that such loading is performed internally by XML processor in
JRE, I do not see an easy way here.
A possible way is that it is possible to create a
javax.xml.validation.Schema explicitly and explicitly perform
Schema.newValidator().validate(...) on the document).
If it is possible to go to the route of cached javax.xml.validation.Schema,
1) We know what resource we are parsing (we know it is a TLD, it is a
web.xml, etc.)
2) How to identify a schema, if several versions of it are available?
I think that xsi:schemaLocation shall be ignored in this case.
What is left are:
- Namespace of the root element
- version attribute.
In some cases those are not in sync,
usually using a newer namespace with older version
but sometimes vise versa. An example:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=351040
(My copy of Eclipse is patched against bug 351040, so I did not notice
its effect for 7.0.50).
In some cases there is no schema, but a DTD.
If we go the cached Schema route, I think it is possible to implement
it by doing validation after parsing, or having some preliminary
parsing step (looking only for namespace and version attribute)
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Deny Put Delete
Thanks neven,mark On Sun, Jan 26, 2014 at 4:00 PM, Neven Cvetkovic neven.cvetko...@gmail.comwrote: On Sun, Jan 26, 2014 at 12:32 AM, Vicky B vickyb2...@gmail.com wrote: if I have a privilege to ask a question on this topic if can anyone help me on how an user fire a put request or delete request ( I am not a hacker) .All my life I just used post and get I never thought about these put and delete, so if someone helps I would appreciate PUT and DELETE type of requests are regularly used in RESTful applications. So, any REST client would be able to send these type of requests, e.g. POSTER extension for Firefox, POSTMAN extension for Chrome, etc... Also, Mark mentioned CURL command line URL client, e.g. curl -X DELETE http://www.somewebsite.here/page curl -X PUT http://www.somewebsite.here/page Good luck! Neven -- *Thanks Regards Vickyb*
Re: Tomcat 7 not honoring maxThreads configuration in catalina.properties and activeCount not going beyond 200
On Friday, January 24, 2014 7:04 PM, Konstantin Kolinko
knst.koli...@gmail.com wrote:
2014/1/24 akshay hiremath akshay...@yahoo.com:
Through some trials found that its not enough to increase the Executors
thread count(maxThreads for Executor element) but also need to increase the
Connectors thread count(maxThreads for Connector element). This behavior is
not actually clearly captured in tomcat documentation says
1. The rules:
http://tomcat.apache.org/lists.html#tomcat-users
- 6. do not top-post, 7. do not send attachments
2. Are you sure that you are actually using an Executor?
In your original port there is no guarantee that the executor
attribute of your Connector
matches the name of an Executor that you declared. If the Executor
does not exist,
the attribute will be ignored.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
1. The rules:
http://tomcat.apache.org/lists.html#tomcat-users
- 6. do not top-post, 7. do not send attachments
Sorry about Top posting. i didn't know about top post issue. Now I'm taking
care of this.
In your original port there is no guarantee that the executor
attribute of your Connector
matches the name of an Executor that you declared. If the Executor
does not exist,
the attribute will be ignored.
I'm using the Executor in the connector. In case if you have missed my original
post portions because of my wrong top posting.
server.xml content:
Executor name=tomcatThreadPool
namePrefix=${server.service-Catalina.executor-tomcatThreadPool.namePrefix}
maxThreads=${server.service-Catalina.executor-tomcatThreadPool.maxThreads}
minSpareThreads=${server.service-Catalina.executor-tomcatThreadPool.minSpareThreads}/
Connector executor=${server.service-Catalina.connector.http1.1.executor}
port=${http.port}
protocol=${server.service-Catalina.connector.http1.1.protocol}
connectionTimeout=${server.service-Catalina.connector.http1.1.connectionTimeout}
redirectPort=${https.port}
acceptCount=${server.service-Catalina.connector.http1.1.acceptCount}
maxKeepAliveRequests=${server.service-Catalina.connector.http1.1.maxKeepAliveRequests}/
catalina.properties:
server.service-Catalina.connector.http1.1.executor=tomcatThreadPool
--Akshay
