Re: [OT] loading images through a Servlet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bill, On 10/2/15 5:02 PM, Bill Ross wrote: > On 10/2/2015 1:55 PM, André Warnier (tomcat) wrote: >> On 02.10.2015 21:18, Bill Ross wrote: >>> Installed FF, HttpFox wasn't installed, installed it but it >>> doesn't show up under developer tools, but I found something >>> and here are my headers: >>> >>> HTTP/1.1 200 OK Etag: W/"resized_2_33068.jpg-1443146350159" >>> Last-Modified: Fri, 25 Sep 2015 01:59:10 GMT [random >>> time in past 22.32455 days] Expires: Sun, 01 Nov 2015 19:12:45 >>> GMT Content-Type: image/jpeg >> >>> Content-Disposition: inline;filename="resized_2_33068.jpg"; >>> filename*=UTF-8''resized_2_33068.jpg >> >> isn't that a giveaway still ? > > It gives some random information for someone to chew on, until they > find this email: > > "resized_" + rand.nextInt(7) + "_" + rand.nextInt(10) + ".jpg" Why bother sending-back a filename *at all*? There's no need to specify the filename in the response: just dump the bytes and call it a day. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWD+GlAAoJEBzwKT+lPKRYAG0QAKtDNPqLWSPYcm2m8o9YMDr7 dEBQWe5kY+TStT7zz8cpRPXKI/d4+TIbRPoKQubv5kMRkXFvoHGJVA3HhDAxWOi5 NUHGiQsiI5R2+D6yRmmP+SeYCWO6X5y61pMPbmE+8uavi78NSWXMbkuIqnaG90FJ 60S4z6+2AJUPfunfZKxLH5ayuHGM5W8JKsmP0PwvxoOmpoKF2YxzWNedvWfP4RTL GgMZSpzs0S515JNbL0aSJMJBUTirpCu/0xE+GXJMF/1+DpMduvBibTcgXZWImESy d/BkmAmkQ49Ffc6IEJGekrLgA7cL56OvKKG1M+HbLnOs8zdpxYB/7CO4ckXCNTjV 3+Ceoo8KHAZCF8PD30Pb1C1y+0Xq5r2Cd48kfUluO2/2kCw0rmrvpuFEJgydGgZG XTnxP3NcB3Q18rytEvAOBCH6ODbDZHkq5xXPPO9racmF9GB+rFMo4gGw2fkJE9hQ YdCPx3RAf12NnVI/QhyeurMFwasvekm5N3qThp9K2F2Zs0ou16QKBTnkpMnEXhcf eHdmcCg77faEW/fUO7ugeHUvH/CRSHDYOTs/tkZZU0kxgA0P82/qcaVPTQBmYyc5 Lhnme4FpHeoEyxJVtRby3DUDXqCdzdK+aFM32GTvA1zPJoL16wKBhF4APJe10PqL nFZVY2jw9AthSl/pDlKV =9j5Y -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: maxFileSize
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jamie, On 10/2/15 11:23 AM, Jamie Jackson wrote: > On Thu, Oct 1, 2015 at 5:25 PM, Christopher Schultz < >> Are you trying to get this value from application code using >> standard APIs, or are you trying to locate the value from within >> something like a Valve, which is Tomcat-specific? > > *Anywhere* is fine with me. > > I'm having some trouble with file uploads in an app. I'm asking > about it in the language's (Lucee's) forums, and people seem to be > hung up on the idea that it's a Tomcat setting (specifically this > maxFileSize setting) -- they're claiming it's got a default of 50MB > that I need to increase, but I'm seeing no evidence of such a > default. (There are apps in the wild, including the manager app, > which have a 50MB limit *specified in web.xml*, but I can find no > evidence that Tomcat, itself, has such a default.) Tomcat has a couple of defaults, but only one of them is Tomcat-specific : maxPostSize - default is 2MiB http://tomcat.apache.org/tomcat-7.0-doc/config/http.html http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html If you are using Java Servlet 3.0 multipart upload, then your file limits may be specified in web.xml like this: ... /tmp 20848820 418018841 1048576 https://docs.oracle.com/javaee/6/tutorial/doc/gmhal.html The spec-defined limits for the max-file-size and max-request-size are both "unlimited" and the default for file-size-threshold is 0 bytes (always store the file on disk). You can also define these limits using an @MultipartConfig annotation on the code. I'm not sure which "wins" if these two are in conflict, but I would hope that the web.xml-defined values would win, since that doesn't require a re-compile of the source to modify them. Lastly, you may have some application-defined limits. Of course, we know nothing about those. But Tomcat has no magical 50MiB limit on anything. (Except for file-uploads specifically for the manager application.) - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWD+ToAAoJEBzwKT+lPKRYgzkP/3j7lNrcgFzFRyU1eC2mseOB PkmDULhJEclRT9K1BpJ6KbfpVgIp+e1eXA9CnEy+Vk6heuAQqN2bqjhKaDTD1C+X a3BVGrNetmXmoDPBxf5i5yUO+UL+OBYNiJsDtjTOquvXd0XE4cCbDZkZrVYSSGKo Uf9oir5AYgx0+5ew4nJSuVaEIgHCESyidJBpxF98gcUPQdTieuHnHzyx2jQI5pXM cqFrPQh1Jx4O3jSI4HWWZbIeujpYtPAAqZXD0i5qyzyS0POKBi8JRit+AP9LJVc6 J+uDUO75sCv6FeUFrfF0sgO5oCSJyBAIkR5IH3fdoXyN2zYv60kVpM1D1C+7hPdL +23edNE7fxWXGc+I9KXZhsOl5HaI/LXL0IBJ+JHDBh+9VU/n5X9LdKFzpBmkWQ5b zUkS6yWelMQh3mS5D9U8HoIbwPVOVud3TujdzJSGCWwOvkY223ccJ2b1S9hjsJuz e+bkzA5GDbc4TBaX04RP/Ti/s6Tt00LZARrOIsCZKTLHqc9hOHoKVsw3LzOnHFNi Quo2wIPDQSXa4NTBAlRIDHFUU7dS6XhGMuQqHrXqQJj8jdpeekINwn5itP1f5nb9 1KHNXEGfuOjg3tiATRg+n5dyGv2Q16OxR/82DkhShY6IW0MR5N+RZ4L2cGMZxOHo D6IV2MYQ4tG1kOuKVM8V =lX2z -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Frequency of Tomcat Native releases
> - ensure the changelog is up to date
Looks like r1681506 could be logged.
> - versions all correct in source
$ find . -type f -exec grep '-H' '1\.1\.' '{}' \;...
./1.1.x/xdocs/index.xml:...TC-Native-1.1.33 released
./1.1.x/xdocs/index.xml:... availability of Tomcat Native 1.1.33 Stable.
./1.1.x/xdocs/news/2015.xml:... TC-Native-1.1.33 released">
> - select and document APR & OpenSSL versions
Please update APR from 1.5.1 to 1.5.2. Please update OpenSSL from 1.0.1m to
1.0.2d.
> - check everything builds correctly
You'd get more volunteers if building APR didn't require MSVC 6.0 or however
you build .dsw. In fact, it'd be nice to see many of these projects adopt
Gradle and do away with many of these old build tools. I tried to build Tomcat
Native once from repository and found my version of Python was too new. Gradle
allows the flexibility of MSVC, GCC, clang.
On Friday, October 2, 2015 5:15 PM, Mark Thomas wrote:
On 02/10/2015 19:01, Justin wrote:
> Can we see more frequent releases of Tomcat Native, especially since
> it statically links OpenSSL on Windows? I was hoping to see a new
> release included in Tomcat 8.0.27. There have been a number of
> changes to both Tomcat Native 1.1.x and OpenSSL 1.0.2.
> http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/?view=log
> https://github.com/openssl/openssl/commits/OpenSSL_1_0_2-stable
I've done the last few tc-native releases because they reached the point
where they really needed to happen. tc-native isn't my area of expertise
so I'd be more than happy to see someone else take this on.
More frequent releases are certainly possible and very much the way we
should be aiming to do things as an Apache project. "Release early and
release often" is the goal.
What contribution are you (or anyone else reading this) willing/able to
make to help this process along?
The tc-native release process is documented (ish) here:
http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/jnirelease.sh?view=annotate
and
https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows
Off the top of my head things that need to be done / checked:
- ensure the changelog is up to date
- versions all correct in source
- select and document APR & OpenSSL versions
- check everything builds correctly
Confirmation that any of the above is ready to go or patches to fix
things if there are gaps will move a release forward.
I can find the time to apply patches and turn the handle on the release
if others can do the work to ensure that svn is in a good state to release.
It is a fairly safe bet that anyone helping out substantially on the
release is going to find themselves with an invitation to become a
Tomcat committer and the RM for the next release.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
