This is the first time I have seen this on a PIC but it is a common error i=
f
the URI processing is not done correctly.  Taking a wild stab in the dark
I'd start looking at the hostname processing.  Not saying this is your
problem but I have seen instances where people assume the URI is always
going to be an IP address so simply count the number of '.' before trying t=
o
process the path.  If this is what is happening the you could get a 414
because it could walk off the end of the string before finding the last '.'=
..

I've seen comments about using Wireshark but this is internal to the PIC so
all you are going to see is the 414 response which is not going to tell you
any more than what you know already.

Anyway I have taken a peek in the Microchip code and I suspect your error i=
s
coming from HTTP_OVERFLOW is defined in HTTP2.h and is use three times.
Might I suggest a break point at each place where it is used and take a loo=
k
at the curHTTP structure.

Alan Melia
w: www.melmac.co.uk


-----Original Message-----
From: Harold Hallikainen [mailto:harold@hallikainen.org]=20
Sent: 21 May 2011 00:30
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] 414 Request-URI Too Long: Buffer overflow detected


>
> Just define HTTP_MAX_DATA_LEN to something enough large.
>
> If you don't define it, it will be defined in Microchip/Includes/TCPIP
> Stack/HTTP2.c and default to 100,
> that mean an uri can't be larger than 100 chars (totally).


Thanks to all that have commented! This looks like what I'm looking for.
Because all the message strings are in an array at the beginning of
HTTP2.c, it is difficult to determine what code is actually outputting
that string. But, this HTTP_MAX_DATA_LEN looks interesting. I'll give that
a try.

THANKS!

Harold



--=20
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!



--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.