Looks like this is the same problem that's addressed in FCREPO-182: https://jira.duraspace.org/browse/FCREPO-182
-- Scott Scott Prater wrote: > We're having some trouble with playing audio files served through > Fedora. In some browsers, the audio will play for a few seconds, then > cut off. However, we always retrieve the full audio datastream via curl > or wget or downloaded through the browser and saved to disk. > > Investigating this problem more, I discovered that Fedora does not set a > 'Content-Length' header when returning managed datastreams. So Tomcat > sets a "Transfer-Encoding: chunked" header, which in turn causes the > Quicktime plugin for Firefox to puke after five seconds (this is a known > problem with Quicktime. According to the HTTP 1.1 RFC, section 3.6.1, > "All HTTP/1.1 applications MUST be able to receive and decode the > "chunked" transfer-coding, and MUST ignore chunk-extension extensions > they do not understand." Oh well.) > > My question is: should Fedora set a Content-Length header when > returning managed datastreams? It does when returning external > datastreams, and when returning inline XML datastreams, so it seems to > me to make sense to do the same for managed datastreams, too. > > Opinions split out in the world on the cost/benefit ratios of > calculating stream lengths beforehand and setting the "Content-Length" > header, or just streaming the data chunked, and letting the client > swallow it in bits at a time. Chunked output is definitely lower > overhead up front, but also fraught with problems on the receiving end; > I'm thinking that in the context of Fedora, where we have the managed > datastream file sizes right at our fingertips, it makes sense to set the > Content-Length header when serving them. > > Thoughts? If no one objects or has a strong opinion against setting the > Content-Length header, I'll open a Fedora feature request on this, and > see what I can do to implement it. > > Below is some debug output showing the headers on a GET request to a > managed datastream. > > -- Scott > > REST API with curl: > $ curl --trace-ascii t1 -u fedoraAdmin:XXXXXX > http://localhost:8080/fedora/objects/1711.dl:URLXHQEEJWTMZ8R/datastreams/THUMB/content > > > t2 > > Here's the output of the request and response headers: > == Info: About to connect() to localhost port 8080 > == Info: Trying 127.0.0.1... == Info: connected > == Info: Connected to localhost (127.0.0.1) port 8080 > == Info: Server auth using Basic with user 'fedoraAdmin' > => Send header, 276 bytes (0x114) > 0000: GET /fedora/objects/1711.dl:URLXHQEEJWTMZ8R/datastreams/THUMB/co > 0040: ntent HTTP/1.1 > 0050: Authorization: Basic xxxxxxxxxxxxxxxxxxx= > 007b: User-Agent: curl/7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5 O > 00bb: penSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > 00e2: Host: localhost:8080 > 0105: Accept: */* > 0112: > <= Recv header, 17 bytes (0x11) > 0000: HTTP/1.1 200 OK > <= Recv header, 27 bytes (0x1b) > 0000: Server: Apache-Coyote/1.1 > <= Recv header, 18 bytes (0x12) > 0000: Pragma: No-cache > <= Recv header, 25 bytes (0x19) > 0000: Cache-Control: no-cache > <= Recv header, 40 bytes (0x28) > 0000: Expires: Wed, 31 Dec 1969 18:00:00 CST > <= Recv header, 58 bytes (0x3a) > 0000: content-disposition: inline; filename="thumb.jpg" > <= Recv header, 26 bytes (0x1a) > 0000: Content-Type: image/jpeg > <= Recv header, 28 bytes (0x1c) > 0000: Transfer-Encoding: chunked > <= Recv header, 37 bytes (0x25) > 0000: Date: Wed, 27 Oct 2010 22:39:08 GMT > <= Recv data, 2458 bytes (0x99a) > > > Old-style SOAP API-A with curl: > $ curl --trace-ascii t1 -u fedoraAdmin:XXXXXX > http://localhost:8080/fedora/get/1711.dl:URLXHQEEJWTMZ8R/THUMB > t2 > > And here's the output: > > == Info: About to connect() to localhost port 8080 > == Info: Trying 127.0.0.1... == Info: connected > == Info: Connected to localhost (127.0.0.1) port 8080 > == Info: Server auth using Basic with user 'fedoraAdmin' > => Send header, 260 bytes (0x104) > 0000: GET /fedora/get/1711.dl:URLXHQEEJWTMZ8R/THUMB HTTP/1.1 > 0038: Authorization: Basic xxxxxxxxxxxxxxxxxx== > 006b: User-Agent: curl/7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5 O > 00ab: penSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > 00d2: Host: localhost:8080 > 00f5: Accept: */* > 0102: > <= Recv header, 17 bytes (0x11) > 0000: HTTP/1.1 200 OK > <= Recv header, 27 bytes (0x1b) > 0000: Server: Apache-Coyote/1.1 > <= Recv header, 18 bytes (0x12) > 0000: Pragma: No-cache > <= Recv header, 25 bytes (0x19) > 0000: Cache-Control: no-cache > <= Recv header, 40 bytes (0x28) > 0000: Expires: Wed, 31 Dec 1969 18:00:00 CST > <= Recv header, 26 bytes (0x1a) > 0000: Content-Type: image/jpeg > <= Recv header, 28 bytes (0x1c) > 0000: Transfer-Encoding: chunked > <= Recv header, 37 bytes (0x25) > 0000: Date: Wed, 27 Oct 2010 22:52:31 GMT > <= Recv data, 1148 bytes (0x47c) > > > -- Scott Prater Library, Instructional, and Research Applications (LIRA) Division of Information Technology (DoIT) University of Wisconsin - Madison [email protected] ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
