Details

      Description

      Hi,

      I recently post a topic on the forum http://share.ez.no/forums/developer/iphone-content-range-header about the support of video on iPhone mobile.

      I try to add videos on our mobile website. Videos are stored through the ezbinaryfile datatype. To provide an URL to the browser, I use the "content/download" approach.
      But it seems that the http header is not correctly formatted. Safari need a partial content (or Content-Range) but eZPublish return a wrong Content-Range.

      Refer : kernel/classes/binaryhandlers/ezfilepassthrough/ezfilepassthroughhandler.php

      Thanks.

      Regards,

      Fabien.

      Steps to reproduce

      Create an image (or video, or whatever)

      Do a range fetch by direct file access, this works (returns 100 bytes from the file):

      curl --range 0-99 http://localhost:81/var/ezwebin_site/storage/images/media/images/supergoogle/334-1-eng-GB/SuperGoogle.jpg -o GOOD
        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                       Dload  Upload   Total   Spent    Left  Speed
        0   100    0   100    0     0  35739      0 --:--:-- --:--:-- --:--:--     0
       
      ll -h GOOD
      -rw-r--r-- 1 gl users  100 2010-05-20 15:40 GOOD
      

      Do a range fetch through content/download, this fails (returns the complete file):

      curl --range 0-99 http://localhost:81/ezwebin_site/content/download/85/334/image/image.jpg -o NOGOOD
        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                       Dload  Upload   Total   Spent    Left  Speed
      100  251k  100  251k    0     0  1125k      0 --:--:-- --:--:-- --:--:-- 6404k
       
      ll -h NOGOOD
      -rw-r--r-- 1 gl users 252K 2010-05-20 15:40 NOGOOD
      

      Apply patch (attached)

      Again, do a range fetch through content/download, now it works (returns 100 bytes from the file):

      curl --range 0-99 http://localhost:81/ezwebin_site/content/download/85/334/image/image.jpg -o NOGOOD-FIX
        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                       Dload  Upload   Total   Spent    Left  Speed
        0   100    0   100    0     0    219      0 --:--:-- --:--:-- --:--:--     0
       
      ll -h NOGOOD-FIX
      -rw-r--r-- 1 gl users  100 2010-05-20 15:51 NOGOOD-FIX
      

      1. ezfilepassthroughhandler.php.patch
        2 kB
        (inactive) Gunnstein Lye
      2. firefox-ogv-header-loop.txt
        109 kB
        Christian Pfeffer Gjengedal

        Issue Links

          Activity

          Hide
          (inactive) Gunnstein Lye added a comment -

          Fixed in
          trunk (4.4.0alpha2) rev. 25295
          stable/4.3 (4.3.1) rev. 25296
          stable/4.2 (4.2.1) rev. 25297

          Show
          (inactive) Gunnstein Lye added a comment - Fixed in trunk (4.4.0alpha2) rev. 25295 stable/4.3 (4.3.1) rev. 25296 stable/4.2 (4.2.1) rev. 25297
          Hide
          Christian Pfeffer Gjengedal added a comment -

          The fix worked perfectly on safari. Chrome was not affected, but Firefox goes haywire asking continuously for the same byte-range after receiving the first 4,4 MB: "Range: bytes=4648960-" firefox-ogv-header-loop.txt

          Show
          Christian Pfeffer Gjengedal added a comment - The fix worked perfectly on safari. Chrome was not affected, but Firefox goes haywire asking continuously for the same byte-range after receiving the first 4,4 MB: "Range: bytes=4648960-" firefox-ogv-header-loop.txt
          Hide
          (inactive) Gunnstein Lye added a comment - - edited

          In reply to comment #051962
          That range seems invalid according to the spec, but we'll have to deal with it, of course.
          http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

          Update: No, it is allowed.
          http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1

          Show
          (inactive) Gunnstein Lye added a comment - - edited In reply to comment #051962 That range seems invalid according to the spec, but we'll have to deal with it, of course. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html Update: No, it is allowed. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1
          Hide
          (inactive) Gunnstein Lye added a comment -

          Reopened due to a problem with Firefox.

          Show
          (inactive) Gunnstein Lye added a comment - Reopened due to a problem with Firefox.
          Hide
          Christian Pfeffer Gjengedal added a comment -

          Also note that the response always is the
          "HTTP/1.1 200 OK" instead of the expected
          "HTTP/1.1 206 Partial content"

          Checking if this is related to my apache configuration.

          Show
          Christian Pfeffer Gjengedal added a comment - Also note that the response always is the "HTTP/1.1 200 OK" instead of the expected "HTTP/1.1 206 Partial content" Checking if this is related to my apache configuration.
          Hide
          (inactive) Gunnstein Lye added a comment -

          In reply to comment #051965
          I don't see how it can send 200 OK, when the code specifies 206.

          Show
          (inactive) Gunnstein Lye added a comment - In reply to comment #051965 I don't see how it can send 200 OK, when the code specifies 206.
          Hide
          André R added a comment -

          Fixed regression in firefox in
          trunk (4.4.0alpha3) rev. 25300
          stable/4.3 (4.3.1) rev. 25301
          stable/4.2 (4.2.1) rev. 25302

          Show
          André R added a comment - Fixed regression in firefox in trunk (4.4.0alpha3) rev. 25300 stable/4.3 (4.3.1) rev. 25301 stable/4.2 (4.2.1) rev. 25302
          Hide
          ezrobot added a comment -

          This issue has been automatically closed due to the lack of activity over a long period of time. It is very likely that it is obsolete, but if you think it is still valid, do not hesitate to reopen it and mention why.

          Show
          ezrobot added a comment - This issue has been automatically closed due to the lack of activity over a long period of time. It is very likely that it is obsolete, but if you think it is still valid, do not hesitate to reopen it and mention why.

            People

            • Assignee:
              (inactive) Gunnstein Lye
              Reporter:
              (inactive) Gunnstein Lye
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: