Opened 4 months ago

Last modified 4 months ago

#6291 new defect

http filesize incorrectly set from 416 response

Reported by: ronag Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: http
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Given the code in http.c

static void parse_content_range(URLContext *h, const char *p)
{
    HTTPContext *s = h->priv_data;
    const char *slash;

    if (!strncmp(p, "bytes ", 6)) {
        p     += 6;
        s->off = strtoull(p, NULL, 10);
        if ((slash = strchr(p, '/')) && strlen(slash) > 0)
            s->filesize = strtoull(slash + 1, NULL, 10);
    }
    if (s->seekable == -1 && (!s->is_akamai || s->filesize != 2147483647))
        h->is_streamed = 0; /* we _can_ in fact seek */
}

The filesize can be set from the content-range of a 416 response. However, this is incorrect as what is given by a 416 response is the current size of a resource which might still be growing. The filesize should only be parsed and set from 200 content-length or 206 content-range, NOT from 416 content-range.

See the http spec for 416, https://tools.ietf.org/html/rfc7233#section-4.4

the sender SHOULD generate a Content-Range header field specifying the current length of the selected representation

Change History (2)

comment:1 Changed 4 months ago by cehoyos

  • Component changed from undetermined to avformat
  • Keywords http added
  • Version changed from unspecified to git-master

comment:2 Changed 4 months ago by ronag

This basically breaks reading any form of growing file from a server. Servers need to add a special case for ffmpeg and check the user-agent and return 200 for any open ended range requests.

Note: See TracTickets for help on using tickets.