Re: [reSIProcate] Content-Length is not taken seriously by SipMessage
There is no problem with the TCP implementation right now IIRC.
This is only UDP, and only an issue for UDP that we _receive_ (we
will never generate a UDP packet with
an incorrect content length).
There are totally hosed, but reasonably widely deployed
implementations that don't know how to count
and create UDP where the content-length is off by 2 (or worse).
Ignoring the content-length for UDP
has improved the ability of some products built with resiprocate to
work in environments with that badness
without suffering (at least initially) from the risks of not honoring
that Content-Length header field.
My proposal is that we make this a configuration option in the stack.
And for clarity I'll repeat that this
affects ONLY what we do with UDP packets we receive. The default
needs to be what the spec says
to do. Those applications that want to take the risk of ultimately
being poisonable for the Postel-maxim based
trade of working with more broken things now should be allowed to do
so by making a single configuration
call at startup.
Thoughts?
RjS
On Aug 4, 2006, at 12:15 PM, Byron Campen wrote:
Derek MacDonald wrote:
It isn't ignored for TCP; it is ignored for UDP. The rational
for this is
people are more likely to get their content length wrong as
opposed to stray
bytes in a UDP packet.
And that works just fine until some bozo notices that the
specification requires, at a MUST level, implementations to ignore
extra cruft in UDP packets, and decides it's a safe place to
piggyback some proprietary information or diagnostics. Yes: bad
them, but it takes two to dance this particular tango, and you've
just volunteered.
/a
Also, we should not encourage bad behavior by letting this slide,
because this sort of mistake kills TCP interop.
Best regards,
Byron Campen
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel