Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert, Robert Koberg wrote: On Feb 6, 2009, at 4:45 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave, Dave Pawson wrote: Only one aspect of security Rob. As needed I'll look at others later. Can you suggest alternatives to achieve what I want, rather than something else? Instead of using Accept header with a magic content-type, how about sending a custom header with some credentials included? You mean like 'Authorization' ? :) Now /that's/ an idea! ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmQyucACgkQ9CaO5/Lv0PDzUQCdFvd5MNBneOJZTilPvqWXtscJ VFYAn3j/njV0akviSr+dpF4fk4coC/a0 =8HwK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
Dave Pawson wrote: Rob, Christopher, Andre. Thanks for the input. As I said to Rob, security is not an issue at the present time. There is no value in the content returned by the 'server' / end point; I'm not trying to make it secure. Just respond less than I otherwise might. Ok, then let me make one final guess and suggestion. If the point is just for your server application to avoid wasting time sending a response to a client that is not yours, and which would not be able to do something useful with it anyway, then the easiest route would probably still be a simple servlet filter. That servlet filter would examine the request headers (say the User-Agent header, which your client would set appropriately), determine if it is or not the appropriate client, and if not send an appropriate HTTP 4xx error response right away, without even letting the request go to the servlet or restlet or whatever. By sending the correct 4xx kind of response, you would let this client know right away, without a doubt, that there is no content here for him, and that he should not even retry, thus avoiding further waste of time for everyone. Google for HTTP response codes to find the most appropriate response in your case. You may even find a ready-made servlet filter that could do that (and many other things besides) here : http://www.tuckey.org/urlrewrite/ A servlet filter does not modify (or require you to modify) the application in any way; it just sees the request before your application does, and can do something to it before the application sees it; it also sees the response of your application after it is produced and can do something to it before it is passed to the client. Also, servlet filters are an entirely portable mechanism, defined in the Servlet Specification, so this would work on any servlet engine. Note again that the above is not in any way a security mechanism, because any client can send whatever User-Agent header it very well pleases. But it would be a very HTTP RFC-compliant way of kindly asking inappropriate clients to just go away and not come back. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
2009/2/7 André Warnier a...@ice-sa.com: You may even find a ready-made servlet filter that could do that (and many other things besides) here : http://www.tuckey.org/urlrewrite/ Looks useful. Tks A servlet filter does not modify (or require you to modify) the application in any way; it just sees the request before your application does, and can do something to it before the application sees it; Yes, that would do. Thanks Andre. regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
Thanks Andre. That paints a good picture! Only generality I'd like to add. The general purpose of my-app web.xml and 'all apps' web.xml. Is it TC 'configuration' (Chaz isn't going to like that, but I do like an overview, even if it's only 80%). I'm saying config, since it provides response mime types, params etc. 2009/2/5 André Warnier a...@ice-sa.com: Part 4 : By some incredible clever setup, that default web.xml happens to contain a table of Mime mappings, telling the default servlet that if what it has to return this time is some file ending in .jpg, it should include a HTTP header Content-type: image/jpeg (so that the browser would know how to handle this correctly). Or if the file ends in .xls, it should return a header Content-type: application/vnd.ms-excel (or something like that).(*) Question: Using your analogy of 'my-app' web.xml being used first, then falling back on 'all-apps' web.xml, can I add 'specials' in the list of mime type? I'm thinking of application/atom+xml So, in other words, if you change something in these Mime mappings, chances are that your Tomcat is going to start returning images while telling the browser they are Word documents, and things like that which make for an entertaining display in the web browser. I'm looking at a mc - mc service, so I'm not expecting browsers. Which is probably not what you want. (Proudly, based on recent teaching by Chuck. Have I got it right, Chuck ?) (*) Of course if the browser is IE, it doesn't matter anyway, because IE will not believe what the server tells it and do its own thing. grin/ If the browser is IE I'll No I won't. Thanks Andre. Nice and clear. (Note the comment about Chaz in the background :-) Close enough! -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
Unless the client specifies that one single mime
type (and no other), I want to reject it
Unless you have an extremely specialized client in mind, you will be rejecting
all requests. No browser will ever limit itself to a single mime type.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
2009/2/6 Caldarale, Charles R chuck.caldar...@unisys.com:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
I'm coming down in favour of a valve, rather than a filter,
to make it container specific,
Which is a good reason not to use a valve. Unless you need access to Tomcat
internals, use a filter.
? Unclear why Charles?
To make it 'filter' all server traffic?
AFAIK I don't need access to any internals.
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
Well, I'n not Chuck, but to answer your question: On Fri, Feb 6, 2009 at 11:39 AM, Dave Pawson dave.paw...@gmail.com wrote: Is a filter the right TC tool for that Charles? Yes Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
From: Dave Pawson [mailto:dave.paw...@gmail.com] I'm coming down in favour of a valve, rather than a filter, to make it container specific, Which is a good reason not to use a valve. Unless you need access to Tomcat internals, use a filter. ? Unclear why Charles? To make it 'filter' all server traffic? AFAIK I don't need access to any internals. Valves only work with Tomcat. Filters work with other servlet containers. Most of the readers of this list would regard portability between servlet containers as a Good Thing. Certainly you should be reading the servlet spec (or a tutorial on it) rather than the Tomcat docs if you want to understand why Tomcat does a numberof the things it does! Valves and filters do similar things at the highest level: they intercept the request and response and allow the valve/filter to do things with those requests and responses. - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
On Feb 6, 2009, at 10:20 AM, Dave Pawson wrote:
2009/2/6 Caldarale, Charles R chuck.caldar...@unisys.com:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
I'm coming down in favour of a valve, rather than a filter,
to make it container specific,
Which is a good reason not to use a valve. Unless you need access
to Tomcat internals, use a filter.
? Unclear why Charles?
To make it 'filter' all server traffic?
AFAIK I don't need access to any internals.
You seem to be making this much more complicated than it needs to be.
First, if you really need your templates to be secure, this won't
solve the problem because someone can easily duplicate your client.
And if you don't /really/ need it secure, why do it?
If you do need it secure, why not just use a security constraint. If
there are just a few people that need to access the templates, you
could use the default tomcat-users.xml setup - easy.
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#MemoryRealm
best,
-Rob
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
? Unclear why Charles?
1) Filter specifications are documened.
2) Filters are not subject to change with every Tomcat release.
To make it 'filter' all server traffic?
Yes, that was what you said you wanted to do. It won't be looking at all
server traffic, just what's directed to your webapp. Other traffic (e.g.,
Tomcat manager) is not affected.
AFAIK I don't need access to any internals.
Then you definately don't want a valve.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
I'm coming down in favour of a valve, rather than a filter,
to make it container specific,
Which is a good reason not to use a valve. Unless you need access to Tomcat
internals, use a filter.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
2009/2/6 Caldarale, Charles R chuck.caldar...@unisys.com:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
Unless the client specifies that one single mime
type (and no other), I want to reject it
Unless you have an extremely specialized client in mind, you will be
rejecting all requests. No browser will ever limit itself to a single mime
type.
That's it. Again, my code, hence very specialised.
No browsers, IE or FF! Just my java end point.
I'm coming down in favour of a valve, rather than a filter, to make it
container specific,
although I can't find much documentation on valve coding. Something that perhaps
checks the request string and header?
Any suggestions please?
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
2009/2/6 Robert Koberg r...@koberg.com: Which is a good reason not to use a valve. Unless you need access to Tomcat internals, use a filter. ? Unclear why Charles? To make it 'filter' all server traffic? AFAIK I don't need access to any internals. You seem to be making this much more complicated than it needs to be. First, if you really need your templates to be secure, this won't solve the problem because someone can easily duplicate your client. And if you don't /really/ need it secure, why do it? Only one aspect of security Rob. As needed I'll look at others later. Can you suggest alternatives to achieve what I want, rather than something else? If you do need it secure, why not just use a security constraint. If there are just a few people that need to access the templates, you could use the default tomcat-users.xml setup - easy. Not what I'm asking for. regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
2009/2/5 Caldarale, Charles R chuck.caldar...@unisys.com:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
Unless the client requests application/xml I want to refuse the
request.
I don't think you quite appreciate the situation yet. An HTTP client does
not *request* any particular mime type; the client *may* specify the mime
types it would like to accept in response,
OK, being precise: Unless the client specifies that one single mime
type (and no other), I want to reject it
with an error. Equally if no mime type is specified I'll refuse to
serve a response other than an error.
but the server is pretty much allowed to return whatever it wants (or
a 406, at the server's discretion). If the client doesn't like a
response type of application/xml, too bad for the client.
Exactly what I'm after.
Is a filter the right TC tool for that Charles?
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
2009/2/6 Caldarale, Charles R chuck.caldar...@unisys.com:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
? Unclear why Charles?
1) Filter specifications are documented.
2) Filters are not subject to change with every Tomcat release.
Makes sense, certainly with TC upgrades!
To make it 'filter' all server traffic?
Yes, that was what you said you wanted to do. It won't be looking at all
server traffic, just what's directed to your webapp. Other traffic (e.g.,
Tomcat manager) is not affected.
AFAIK I don't need access to any internals.
Then you definately don't want a valve.
Understood. Thanks.
btw, The Sun specs page is a bit convoluted.
http://java.sun.com/products/servlet/download.html
2.4 final or
2.5 maint release.
which is TC 6 compliant to please?
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
2.4 final or
2.5 maint release.
which is TC 6 compliant to please?
RTFM:
http://tomcat.apache.org/
It's on the *first* page...
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
Is it TC 'configuration' I'm saying config, since
it provides response mime types, params etc.
Strictly speaking, it's not Tomcat configuration, but webapp configuration,
since the elements and values are defined by the servlet spec. The term
Tomcat configuration is normally limited to those Tomcat-unique settings in
files such as server.xml, catalina.properties, and context.xml.
Question: Using your analogy of 'my-app' web.xml being
used first, then falling back on 'all-apps' web.xml, can
I add 'specials' in the list of mime type? I'm thinking
of application/atom+xml
Yes.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
Dave Pawson wrote: Thanks Andre. That paints a good picture! Only generality I'd like to add. The general purpose of my-app web.xml and 'all apps' web.xml. Is it TC 'configuration' (Chaz isn't going to like that, but I do like an overview, even if it's only 80%). I'm saying config, since it provides response mime types, params etc. 2009/2/5 André Warnier a...@ice-sa.com: Part 4 : By some incredible clever setup, that default web.xml happens to contain a table of Mime mappings, telling the default servlet that if what it has to return this time is some file ending in .jpg, it should include a HTTP header Content-type: image/jpeg (so that the browser would know how to handle this correctly). Or if the file ends in .xls, it should return a header Content-type: application/vnd.ms-excel (or something like that).(*) Question: Using your analogy of 'my-app' web.xml being used first, then falling back on 'all-apps' web.xml, can I add 'specials' in the list of mime type? I'm thinking of application/atom+xml Looking at a comment in the main conf/web.xml : !-- When serving static resources, Tomcat will automatically generate -- !-- a Content-Type header based on the resource's filename extension, -- !-- based on these mappings. Additional mappings can be added here (to -- !-- apply to all web applications), or in your own application's web.xml -- !-- deployment descriptor. -- So I guess yes, they are cumulated, if that is your question. So, in other words, if you change something in these Mime mappings, chances are that your Tomcat is going to start returning images while telling the browser they are Word documents, and things like that which make for an entertaining display in the web browser. I'm looking at a mc - mc service, so I'm not expecting browsers. Well, in your logfiles then probably. XML parsers might also be rather partial to input files with the wrong type. Which is probably not what you want. (Proudly, based on recent teaching by Chuck. Have I got it right, Chuck ?) (*) Of course if the browser is IE, it doesn't matter anyway, because IE will not believe what the server tells it and do its own thing. grin/ If the browser is IE I'll No I won't. Thanks Andre. Nice and clear. (Note the comment about Chaz in the background :-) Close enough! Yeah. But coming from Chuck, I think that's praise enough. I'm all thrilled that he didn't find anything in it that was contrary to the Servlet Specification, paragraph x.y. Or else he was distracted. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
Dave Pawson wrote:
2009/2/6 Caldarale, Charles R chuck.caldar...@unisys.com:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
Unless the client specifies that one single mime
type (and no other), I want to reject it
Unless you have an extremely specialized client in mind, you will be rejecting
all requests. No browser will ever limit itself to a single mime type.
That's it. Again, my code, hence very specialised.
No browsers, IE or FF! Just my java end point.
I believe that what Chuck is trying to tell you - and in many more words
than his - is this :
Your service, whatever it is, will have a listening TCP port, waiting
for requests from your clients.
Thus, any of many available programs out there (not talking only about
browsers), can connect to that TCP port, and basically send anything
they want to it. Including things resembling the requests you are
expecting, with whatever HTTP headers they want to specify, including
those which you would maybe use to attempt to distinguish your genuine
clients from the others.
Thus, rejecting requests on the base of something they include or not,
unless the something is some secret encrypted key available only to your
server and its genuine clients, will not be a good enough measure if
your goal is to avoid someone downloading something from your server
that they shouldn't.
I (or anyone else on this list) can fake any such HTTP request, at any
time, within 1 minute of you giving us the hostname and port, and
download one of your xml templates.
And we would not even have to write any new program to do it.
If there is a secret key, and if it is fixed, then anyone once capturing
a packet between your clients and your server, would be able to re-use
that key and fake one of your clients forever.
If the key is variable, but based on some simple algorithm, then 1) you
would still have to develop the algorithm and 2) unless you are a
cryptographic expert, someone will break it if there is enough interest
to justify it, and even only for the fun of it.
If security is one of your purposes thus, do not try to use things like
content-type headers or the like, use a secure form of communication
developed by experts and available for free, such as HTTPS.
You would just have to plug-in the pieces, and then develop your
application as if the security layer wasn't even there.
And if security is not in the picture, then forgive me the above
lecture, I got lost somewhere along about what your purpose really is.
But if you're still interested, I have a similar lecture about the
difference between Valves and servlets (or servlet filters), and why one
may be more adapted than the other to any particular purpose.
Not at any deep Tomcat/Java level though.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave, Dave Pawson wrote: Only one aspect of security Rob. As needed I'll look at others later. Can you suggest alternatives to achieve what I want, rather than something else? Instead of using Accept header with a magic content-type, how about sending a custom header with some credentials included? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmMr2kACgkQ9CaO5/Lv0PDpOwCeLOjsJIuh6rYxy9l3FJwEIWus u+EAoLCF6wKoKneKZIXHQ6gGjJat3FtN =K4uu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
On Feb 6, 2009, at 4:45 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave, Dave Pawson wrote: Only one aspect of security Rob. As needed I'll look at others later. Can you suggest alternatives to achieve what I want, rather than something else? Instead of using Accept header with a magic content-type, how about sending a custom header with some credentials included? You mean like 'Authorization' ? :) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
Rob, Christopher, Andre. Thanks for the input. As I said to Rob, security is not an issue at the present time. There is no value in the content returned by the 'server' / end point; I'm not trying to make it secure. Just respond less than I otherwise might. Thanks for the 'lecture' Andre. I now appreciate what Rob said. 2009/2/6 André Warnier a...@ice-sa.com: And if security is not in the picture, then forgive me the above lecture, I got lost somewhere along about what your purpose really is. Primarily getting my head around TC? Having looked at http://tomcat.apache.org/tomcat-6.0-doc/api/index.html and file:///d/documentation/java/servletSpec2.5/javadocs/index.html I can't see how I can get hold of the information anyway, so I'll try that within the restlet code. But if you're still interested, I have a similar lecture about the difference between Valves and servlets (or servlet filters), and why one may be more adapted than the other to any particular purpose. Not at any deep Tomcat/Java level though. I've wasted enough list time Andre. Many thanks for the offer. I may well come back for more on security, depending on what sort of traffic I get. regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
I want to 'reject' (if that's the right word) any http get with mime type != application/xml I see in web.xml in the conf directory mime-mapping extensionxml/extension mime-typeapplication/xml/mime-type /mime-mapping Is this the right place to do it please? regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place
to constrain the mime type?
I want to 'reject' (if that's the right word) any http get
with mime type != application/xml
Do you mean .html and .jsp are not valid? That might make life interesting.
It will be difficult to stop clients from accepting at least text/html in
addition to application/xml.
I see in web.xml in the conf directory
mime-mapping
extensionxml/extension
mime-typeapplication/xml/mime-type
/mime-mapping
Is this the right place to do it please?
No - that would pretty much certainly break things. Also, AFAIK, that's only
used for responses, so that the container can set the mime type properly for
whatever resource is being returned.
You probably need to do this in a filter that will see the request before your
servlets do.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
2009/2/5 Caldarale, Charles R chuck.caldar...@unisys.com:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place
to constrain the mime type?
I want to 'reject' (if that's the right word) any http get
with mime type != application/xml
Do you mean .html and .jsp are not valid? That might make life interesting.
It will be difficult to stop clients from accepting at least text/html in
addition to application/xml.
Wrong way round?
Background.
Currently I generate a template (outline XML) for an atom feed I run.
This is 'wrong' (IMHO). I have a tiny server visible to the web.
I want to use REST to 'get' this template (hence restrict it to application/xml)
so if you|anyone does a GET on this url I want to 'refuse' you content, by
returning an http 'error'. code TBD, I'm sure Roy defined one :-)
So unless the GET is for application/xml I want to return nothing.
I see in web.xml in the conf directory
mime-mapping
extensionxml/extension
mime-typeapplication/xml/mime-type
/mime-mapping
Is this the right place to do it please?
No - that would pretty much certainly break things. Also, AFAIK, that's only
used for responses, so that the container can set the mime type properly for
whatever resource is being returned.
You probably need to do this in a filter that will see the request before
your servlets do.
Makes sense (in my very limited view of http)
Check if the GET is for the 'desired' mime type.
If it isn't... respond accordingly. at the header level?
10.4.16 415 Unsupported Media Type
The server is refusing to service the request because the entity of
the request is in a format not supported by the requested resource for
the requested method.
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)
Does that make sense?
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
On Feb 5, 2009, at 1:28 PM, Caldarale, Charles R wrote:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place
to constrain the mime type?
I want to 'reject' (if that's the right word) any http get
with mime type != application/xml
The client doesn't send the mime-type it is requesting. It sends some
set of types it is willing to accept. For example:
accept=text/html,application/xhtml+xml,application/xml
Why not just always send XML? or if they don't have an accept entry
for application/xml the send and error with status code 406:
406 Not Acceptable
The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable
according to the accept headers sent in the request.
Unless it was a HEAD request, the response SHOULD include an entity
containing a list of available entity characteristics and location(s)
from which the user or user agent can choose the one most appropriate.
The entity format is specified by the media type given in the Content-
Type header field. Depending upon the format and the capabilities of
the user agent, selection of the most appropriate choice MAY be
performed automatically. However, this specification does not define
any standard for such automatic selection.
Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the
request. In some cases, this may even be preferable to sending a
406 response. User agents are encouraged to inspect the headers
of
an incoming response to determine if it is acceptable.
If the response could be unacceptable, a user agent SHOULD temporarily
stop receipt of more data and query the user for a decision on further
actions.
best,
-Rob
Do you mean .html and .jsp are not valid? That might make life
interesting. It will be difficult to stop clients from accepting at
least text/html in addition to application/xml.
I see in web.xml in the conf directory
mime-mapping
extensionxml/extension
mime-typeapplication/xml/mime-type
/mime-mapping
Is this the right place to do it please?
No - that would pretty much certainly break things. Also, AFAIK,
that's only used for responses, so that the container can set the
mime type properly for whatever resource is being returned.
You probably need to do this in a filter that will see the request
before your servlets do.
- Chuck
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
On Feb 5, 2009, at 1:36 PM, Dave Pawson wrote:
2009/2/5 Caldarale, Charles R chuck.caldar...@unisys.com:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place
to constrain the mime type?
I want to 'reject' (if that's the right word) any http get
with mime type != application/xml
Do you mean .html and .jsp are not valid? That might make life
interesting. It will be difficult to stop clients from accepting
at least text/html in addition to application/xml.
Wrong way round?
Background.
Currently I generate a template (outline XML) for an atom feed I run.
This is 'wrong' (IMHO). I have a tiny server visible to the web.
I want to use REST to 'get' this template (hence restrict it to
application/xml)
so if you|anyone does a GET on this url I want to 'refuse' you
content, by
returning an http 'error'. code TBD, I'm sure Roy defined one :-)
So unless the GET is for application/xml I want to return nothing.
Doesn't work that way. You basically want to authenticate the user
(you) not restrict by mime-type, which IO believe you mean the accept
header, which most browser will include the application/xml
-Rob
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
Hi Rob
2009/2/5 Robert Koberg r...@koberg.com:
On Feb 5, 2009, at 1:28 PM, Caldarale, Charles R wrote:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place
to constrain the mime type?
I want to 'reject' (if that's the right word) any http get
with mime type != application/xml
The client doesn't send the mime-type it is requesting. It sends some set of
types it is willing to accept. For example:
accept=text/html,application/xhtml+xml,application/xml
Why not just always send XML? or if they don't have an accept entry for
application/xml the send and error with status code 406:
Tks for that. (I said my knowledge of http was 'limited' :-)
Let me rephrase my request.
Unless the client requests application/xml I want to refuse the
request.
406 Not Acceptable
The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable
according to the accept headers sent in the request.
Turned round to this format, that response seems incorrect Rob.
What should I respond with when the 'customer' (client) says
please give me (and I don't want to - my definition of an
inappropriate request)
Unless it was a HEAD request,
grin/ Let me resolve the simple ones first please!
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
Unless the client requests application/xml I want to refuse the
request.
I don't think you quite appreciate the situation yet. An HTTP client does not
*request* any particular mime type; the client *may* specify the mime types it
would like to accept in response, but the server is pretty much allowed to
return whatever it wants (or a 406, at the server's discretion). If the client
doesn't like a response type of application/xml, too bad for the client.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
Dave Pawson wrote:
Hi Rob
2009/2/5 Robert Koberg r...@koberg.com:
On Feb 5, 2009, at 1:28 PM, Caldarale, Charles R wrote:
From: Dave Pawson [mailto:dave.paw...@gmail.com]
Subject: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place
to constrain the mime type?
Just to clear up your question above : no.
In many more words :
Part 1:
the file ${CATALINA_HOME}/conf/web.xml is the default, tomcat-wide
web.xml. It plays the same role as each webapp's web.xml that resides
in the WEB-INF/web.xml of each webapp. But each of these applies only
to its particular webapp, while the general webapp first named applies
to all webapps, by default.
Part 2:
In each webapp, there is a default servlet provided by Tomcat, whose
role is to handle each request that was directed to this webapp, but for
which no specific url-mapping could be found in that webapp's web.xml.
That default servlet handles, for instance, requests for static content,
like /mywebapp/my_dog.jpg.
Part 3 :
When this servlet returns some static content, and since it is after all
part of a specific webapp, it looks first in it's own webapp's web.xml
for paramaters applicable to him. But since it probably doesn't find
any, it defaults to the parameters of the default tomcat-wide web.xml,
which is... ${CATALINA_HOME}/conf/web.xml.
Part 4 :
By some incredible clever setup, that default web.xml happens to contain
a table of Mime mappings, telling the default servlet that if what it
has to return this time is some file ending in .jpg, it should include
a HTTP header Content-type: image/jpeg (so that the browser would
know how to handle this correctly). Or if the file ends in .xls, it
should return a header Content-type: application/vnd.ms-excel (or
something like that).(*)
So, in other words, if you change something in these Mime mappings,
chances are that your Tomcat is going to start returning images while
telling the browser they are Word documents, and things like that which
make for an entertaining display in the web browser.
Which is probably not what you want.
(Proudly, based on recent teaching by Chuck. Have I got it right, Chuck ?)
(*) Of course if the browser is IE, it doesn't matter anyway, because IE
will not believe what the server tells it and do its own thing.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
place to constrain the mime type?
(*) Of course if the browser is IE, it doesn't matter anyway,
because IE will not believe what the server tells it and do
its own thing.
Now that part is absolute truth.
(The rest was close enough.)
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
