[FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary

[Michael Niedermayer]

On Thu, Feb 26, 2015 at 04:28:54PM +0100, Carl Eugen Hoyos wrote:
> On Thursday 26 February 2015 03:31:39 pm Derek Buitenhuis wrote:
> > On 2/26/2015 2:09 PM, Carl Eugen Hoyos wrote:
> > > +            snprintf(header, len + 3, "%s\r\n", s->headers);
> >
> > This does not necessarily work on windows. The C standard idctates that in
> > text mode, \n is translated to the system's native newline.
> >
> > Use memcpy and 0x0D / 0X0A / 0x00.
> 
> New patch attached.
> 
> > This may also accidentally allow for headers to end with '\n\r\n',
> > wouldn't it?
> 
> Yes, I don't know if this is a problem.
> 
> Thank you, Carl Eugen

>  http.c |   12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 6114a18a8dd0b1737c844b18a839a6ef99617145  patchhttpcrlf2.diff
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 55dcb6e..59e5acb 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -312,9 +312,17 @@ static int http_open(URLContext *h, const char *uri, int flags,
>  
>      if (s->headers) {
>          int len = strlen(s->headers);
> -        if (len < 2 || strcmp("\r\n", s->headers + len - 2))
> +        if (len < 2 || strcmp("\r\n", s->headers + len - 2)) {
> +            char *header = av_malloc(len + 3);
> +            if (!header)
> +                return AVERROR(ENOMEM);
> +            memcpy(header, s->headers, len);
> +            memcpy(header + len, "\r\n\0", 3);

there should be a loop that replaces each sequence of any \n\r
by a single crlf sequency using no \r \n codes but only litteral bytes
and also ensure that one such sequence is at the end

if you only want t fix the end, then existing \r and \n should be
stripped and crlf be added litterally without use of \r\n but
literal byte values

to repeat, the input checks should use \r\n the output should not
we assume the user would provide headers in the platforms encoding
while we need http encoding on the output side

i hope above is correct and not missing something

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150309/27ab0b0e/attachment.asc>