eliminating MAXHEADERSIZE

Florian Schlichting fschlich at CIS.FU-Berlin.DE
Wed Jun 30 12:46:17 UTC 2010


different issue, different mail...

> >NB: I believe the only place where MAXHEADERSIZE describes allowable
> >line length is here in ARTparseheader, so I think it could perhaps be
> >replaced by a check against 1000 in order to achieve the fix mentioned
> >in include/inn/options.h:118?
> 
> That is to say using another variable for the other calls to MAXHEADERSIZE?
> We have SMBUF (256 bytes) and BIG_BUFFER (8192 bytes).  We could create
> MED_BUFFER (1024 bytes) for a medium buffer...
> 
> And change MAXHEADERSIZE to 1000?  (I checked that it is really 1000, and
> not 998 with '\r\n' -- they are currently included in the count.)
> I believe we could also change the name to MAXARTLINESIZE because it
> is otherwise a bit confusing.  The size of a header field is unlimited.
> And the size also applies to the lines of the body.
> 
> Is it what you meant?

yes, and I think it's a good idea to call it something other than
MAXHEADERSIZE - how about MAXARTLINELENGTH, or is there a reason why
we'd speak of a line size rather than a line length?

Please be careful when carrying out the substitutions, though, I'm not
really familiar with all the occurrences and I think I was wrong when I
said above that innd/art.c:848 is the only place where it really means line
length; I think innd/art.c:1438 should also become MAXARTLINELENGTH and
not MED_BUFFER. I've had another look at the other occurrences and I
think that should be it, but...

Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5557 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20100630/3f71756f/attachment.bin>


More information about the inn-workers mailing list