Bug 130100

	When webalizer encounters an Apache log entry whose request
	(GET/HEAD/POST) exceeds 512 bytes in length, it emits the
	following warning while processing:

Warning: Truncating oversized request field [647]

	The number shown correlates with the log file line number which
	caused the warning.  In this case, here is the log entry:

89.128.3.8 - - [31/Dec/2008:12:34:00 -0800] "GET /category/trans/im-kid-dracula/fonts/category/blog/page/2/trans/im-kid-dracula/trans/dream-penguin-adventure/trans/sd-hiryu-no-ken-ex/contact/trans/nekketsu-street-basket-ganbare-dunk-heroes/fonts/contact/trans/dream-penguin-adventure/donations/category/blog/category/blog/contact/contact/contact/trans/sd-hiryu-no-ken-ex/trans/karnov/fonts/trans/doki-doki-panic/trans/nettou-the-king-of-fighters-96/trans/sd-hiryu-no-ken-ex/category/blog/trans/ys-iii-wanderers-from-ys/category/blog/trans/tomorrows-joe/trans/fonts/ HTTP/1.1" 200 5300 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

	This is indeed a long URL -- the content request portion is ~517
	bytes long.  RFCs do not define the length, so each web server has
	an arbitrary limit.  Using Apache as an example: Apache 1.x supports
	up to 4000 characters, while 2.x supports up to 8192.  Present-day
	web browsers will submit anywhere between 65536 and 190000
	characters.

	webalizer's code, however, imposes a limit of 512.  The define is
	called MAXURLH located in webalizer.h at line 19.

	I feel this value should be increased to something more reasonable,
	given that URLs in this day and age are often longer than they were
	when webalizer was originally written.

	I fully acknowledge that this issue should be reported upstream,
	but I've a gut feeling administrators/users have done this with
	either no response or rejection.  (This is an assumption on my
	part.)

	I have not verified that the code change will not break anything
	internally, but based on reading Debian and OpenSuSE mailing lists,
	they have increased this value in the past without harm.

Fix: 

Increase MAXURLH from 512 to something larger; I propose 2048.  I
	have concerns increasing it to 4096, as I'm not sure how this variable
	interacts or relates to the "MAXURL" variable (which is 4096).
How-To-Repeat: 	Place an entry in your webserver log file which contains a request
	that exceeds 512 bytes and run webalizer.