br1 wrote: > > > Christopher Schultz-2 wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Br1, >> >> br1 wrote: >>> Do you think this limit will be increased in the next versions? >>> >>> In theory, no limit is imposed by the protocol itself. I would tend to >>> think >>> JK should at least support what the JK supported platforms support. >> >> The source code /is/ available; you could try poking around for where >> that limit is set. There are a lot of files, but grep could help. >> >> For instance, I found this (in jk 1.2.26): >> >> ./common/jk_uri_worker_map.h:#define JK_MAX_URI_LEN 4095 >> >> ..which could suggest that the max URL length is 4k, not 2k. Maybe >> that's not the right setting. >> >> I can see this in the IIS source files: >> >> ./iis/jk_isapi_plugin.c: char uri[INTERNET_MAX_URL_LENGTH]; >> >> INTERNET_MAX_URL_LENGTH does not seem to be defined in mod_jk's source, >> so it probably comes from IIS itself. Is it possible that IIS is the one >> ruining your day? I don't know of a good IIS API resource, so you might >> have to track this one down yourself. >> >> Just a thought. >> - -chris >> > > Hi Chris, > > Thank you for your reply. > The key factor is: with the JK connector I get the error, without the JK > connector I don't get the error. :-) > > As I said previously, it also shows up with non-JK redirected URLs, and it > also comes out with just long query strings. > For instance: > /testalias/testpage.asp?param=[put 3000 "a"s here] > > The above works without the JK connector, but it does not work with the JK > connector. > I don't call it an IIS problem, I call it a JK connector problem. > > About recompiling, I am really not that good at this, and I would prefer > not to take this responsibility.. I am quite protective with my prod > servers. :-) > Should this be a bug, I would prefer to wait someone that knows where to > put his hands on the code. And avoid the need to correct and recompile > every time a new version comes out.. > > Thank you for the hints, > Br1. >
Ok, I am starting to understand better what is happening, there seem to be two problems here. 1 - The max URL length for IIS 5 is about 2k or so. This cannot be changed probably. When trying to open a URL that exceeds this limit, the JK ISAPI connector returns "The data area passed to a system call is too small" to the browser. My suggestion to the developers here, could you please intercept the error and maybe return a "413 Request Entity Too Large" message? This is what happens for instance with Ionics rewrite (see 31 october 2008 release, http://www.codeplex.com/IIRF/SourceControl/ListDownloadableCommits.aspx) Edit: without the JK ISAPI connector, IIS returns "414 - Request - URI too long". I suspect that the above 413 message applies to point (2) below. 2 - When opening a "short" URL that contains GET data, and the total length of URL+parameters exceeds the max URL length, the JK ISAPI connector returns exactly the same message: "The data area passed to a system call is too small". This should not happen if the URL portion does not exceed the max URL length, and the right behaviour of the JK connector should be to either serve the page or pass the request over to IIS. Please note that the maximum request data on IIS 5 with URLScan installed defaults to 4k, but can be raised (I set it at 16k). Also note that, as I already wrote, in this case the JK connector breaks ALL requests whose URL+query string exceeds the max URL length value, not just the ones being AJP redirected to Tomcat. 3 - Chris, taking a look at the code shed some light, but don't ask me to change the code, I can hardly guess it is written in c language. :-) Please let me know if I should do further tests (though there is nothing more I can think of). Thank you, Br1. -- View this message in context: http://www.nabble.com/JK-connector-fails-with-long-URLs-tp21443475p21545131.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
