CRLF problem with custom headers when playing hls streams on windows

[lorus]

HTTP headers must be terminated by a CRLF, but when invoking ffmpeg from windows cmd there is no possibility to add CRLF:

ffmpeg -v 9 -loglevel 99 -headers "User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16" -i http://pebbles112-lh.akamaihd.net/i/daserste_1@97481/index_900_av-p.m3u8?sd=6&b=0-1000&rebase=on
ffmpeg version N-59488-g8a1714a Copyright (c) 2000-2014 the FFmpeg developers
  built on Jan  2 2014 22:01:54 with gcc 4.8.2 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-li
bass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopenco
re-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidst
ab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      52. 59.100 / 52. 59.100
  libavcodec     55. 47.100 / 55. 47.100
  libavformat    55. 22.102 / 55. 22.102
  libavdevice    55.  5.102 / 55.  5.102
  libavfilter     4.  0.103 /  4.  0.103
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
  libpostproc    52.  3.100 / 52.  3.100
Splitting the commandline.
Reading option '-v' ... matched as option 'v' (set logging level) with argument '9'.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument '99'.
Reading option '-headers' ... matched as AVOption 'headers' with argument 'User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16'.
Reading option '-i' ... matched as input file with argument 'http://pebbles112-lh.akamaihd.net/i/daserste_1@97481/index_900_av-p.m3u8?sd=6'.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option v (set logging level) with argument 9.
Successfully parsed a group of options.
Parsing a group of options: input file http://pebbles112-lh.akamaihd.net/i/daserste_1@97481/index_900_av-p.m3u8?sd=6.
Successfully parsed a group of options.
Opening an input file: http://pebbles112-lh.akamaihd.net/i/daserste_1@97481/index_900_av-p.m3u8?sd=6.
[http @ 02b23200] No trailing CRLF found in HTTP header.
[http @ 02b23200] request: GET /i/daserste_1@97481/index_900_av-p.m3u8?sd=6 HTTP/1.1
Accept: */*
Range: bytes=0-
Connection: close
Host: pebbles112-lh.akamaihd.net
User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16

[http @ 02b23200] header='HTTP/1.0 408 Request Time-out'
[http @ 02b23200] http_code=408
[http @ 02b23200] HTTP error 408 Request Time-out
http://pebbles112-lh.akamaihd.net/i/daserste_1@97481/index_900_av-p.m3u8?sd=6: Input/output error

in linux bash you can work around with:

ffmpeg -headers 'User-Agent: bar'$'\r\n' -i http://hard.com/foo.flv

... but there is no similar workaround for windows, so I guess the CRLF has to be hardcoded.

I'm wondering why CRLF isn't already hardcoded in http.c or is there any other solution?

[lorus]

If you now ask why I'm not using -user-agent ... I have posted the wrong snippet ... thats the correct command line I'm trying to get work:

ffmpeg -v 9 -loglevel 99 -headers "X-Forwarded-For: 160.53.186.194" -i    http://pebbles112-lh.akamaihd.net/i/daserste_1@97481/index_900_av-p.m3u8?sd=6&b=0-1000&rebase=on

... but error [http @ 02b23200] No trailing CRLF found in HTTP header. is the same

[Timur]

I encountered a similar problem and agree with the author that "\r\n" should be hardcoded into http.c.

HTTP 1.1 protocol says:

generic-message = start-line
                  *(message-header CRLF)
                  CRLF
                  [ message-body ]

message-header = field-name ":" [ field-value ]

That means that "\r\n" (CRLF) MUST follow each header. So why specify it manually inside the 'headers' option?

I would also like to note that this is not only Windows-specific problem. That is true that under Linux it is easier to bypass but the inconvenience still exists.

[Carl Eugen Hoyos]

​http://ffmpeg.org/pipermail/ffmpeg-devel/2015-February/169370.html

[Carl Eugen Hoyos]

Fixed since 8e67599505e3b0a968227a1dcd40020dff874001 (and 2e2b44baba575a33aa66796bc0a0f93070ab6c53)