Ask Your Question

Betezed's profile - activity

2015-01-15 07:44:51 -0500 received badge  Taxonomist
2014-04-25 08:17:17 -0500 received badge  Famous Question (source)
2014-03-31 05:09:39 -0500 commented answer Dynamic large objects : Range bytes very SLOW

Hi Bertrand V, I didn't do anything. Some OVH side changes were made. I think they just changed the way they handled the range feature for the dynamic large objects. Are you facing this delay issue ?

2014-03-31 02:29:30 -0500 received badge  Notable Question (source)
2014-03-13 00:49:01 -0500 received badge  Famous Question (source)
2014-02-28 03:31:42 -0500 received badge  Supporter (source)
2014-02-28 03:31:36 -0500 commented answer Dynamic large objects : Range bytes very SLOW

Ok you were right, because I used swift through OVH, and some changes were made. Now everything works like a charm ! Thanks again for your helpful answer(s) ("s" because you helped me twice !)

2014-02-28 03:29:26 -0500 received badge  Popular Question (source)
2014-01-31 06:47:36 -0500 commented answer Dynamic large objects : Range bytes very SLOW

Hi, I'm answering very late, but I wanted to thank you for your answer (again !) We found some new ideas to avoid this delay, but we don't know for sure why it took so long... Anyway, again thanks for replying and helping ! Bye :)

2014-01-17 06:16:18 -0500 received badge  Scholar (source)
2014-01-15 05:26:43 -0500 asked a question Dynamic large objects : Range bytes very SLOW

Hi everyone,

First of all, please forgive me for my english, I hope you'll understand everything. If you have any question, please ask :)

For some reason, I need to get a dynamic large object with the Range functionality. I have a file movie.iso which is a manifest merging 2 files : movie-1.iso (4Go) and movie-2.iso (3,2Go) For testing purpose, I'm using telnet on a temporary URL :

telnet 80 
GET /v1/AUTH_abcdefghijklm0123456789/ean_chris_0001/movie.iso?temp_url_sig=wxcvbn1213456&temp_url_expires=1389741206 HTTP/1.1
range: bytes=32-42
Connection: Close

So basically, I'm asking for 11 bytes. The server answers correctly after more that 2 min

HTTP/1.1 206 Partial Content
Content-Length: 11
Accept-Ranges: bytes
Last-Modified: Wed, 11 Dec 2013 01:02:06 GMT
Content-Range: bytes 32-42/7215073280
X-Object-Manifest: container/movie-
X-Timestamp: 1386728331.26093
Etag: "xxxxxxxxxxxxxxxxxxxxxxxx"
Content-Type: application/x-iso9660-image
Content-Disposition: attachment; filename=movie.iso
X-Trans-Id: yyyyyyyyyyyyyyyyyyyy
Date: Wed, 15 Jan 2014 11:03:27 GMT
Connection: close

However, when I'm doing this exact same operation (meaning asking for 11 bytes with a range request) on a non-manifest file (for example on movie-1.iso or movie-2.iso), the response is almost instantaneous.

I think that this long delay when asking for some bytes on a manifest file is caused by the fact that the manifest starts with the merging operation and when it finishes its merging, it sends me back the 11 bytes I asked.

So my question is : Do you have any idea on what to do in order to avoid this long delay ?

Thank you in advance for reading and maybe trying to solve my issue ... !

2014-01-15 05:06:54 -0500 received badge  Notable Question (source)
2013-11-19 20:13:30 -0500 received badge  Popular Question (source)
2013-11-14 03:15:19 -0500 commented answer Static Large Objects

Hi, Thanks for your quick answer. I've done what you suggested, and found out that static large objects are not enabled here because the server accepted this header without any questions I guess I'll only use the dynamic large objects feature then. Thank you again for your help **Torgomatic**

2013-11-13 10:08:35 -0500 asked a question Static Large Objects

Hi !

I've some issues trying to use the static large objects feature (while dynamic large objects feature works perfectly)

( )

When I send my "multipart" file with its manifest, followed by the multipart-manifest=put query (json format), everything is successful.

Manifest file :

        "path": "/bar/musique.mp3",
        "etag": "b77211f7a0c76e3b7ad87d88f605e21d",
        "size_bytes": 3256896
        "path": "/foo/toto.txt",
        "etag": "4b6678c41d52dadfb385a4a078c79a14",
        "size_bytes": 20

Request :

curl -X PUT -i -H "X-Auth-Token: abcdef0123456789" -T ./manifest.json ""

Response :

HTTP/1.1 100 Continue

HTTP/1.1 201 Created
Last-Modified: Wed, 13 Nov 2013 16:00:15 GMT
Content-Length: 0
Etag: 0123456789abcdeg
Content-Type: text/html; charset=UTF-8
X-Trans-Id: 1s5d4f6s4fdf1s56fd47d56f514s
Date: Wed, 13 Nov 2013 16:00:15 GMT

The thing is when I try to get the whole file by using the GET method on the manifest, I only get the manifest in its json format, instead of downloading the whole reunited file.

Using the HEAD request returns Content-Length with the size of the manifest itself instead of size of the large object I try to download.

Request :

curl -X HEAD -i -H "X-Auth-Token: abcdef0123456789" ""

Response :

HTTP/1.1 200 OK
Content-Length: 259
Accept-Ranges: bytes
Last-Modified: Wed, 13 Nov 2013 16:00:15 GMT
Etag: 0123456789abcdeg
X-Timestamp: 123456789.36351
Content-Type: application/octet-stream
X-Trans-Id: 1s5d4f6s4fdf1s56fd47d56f514s
Date: Wed, 13 Nov 2013 16:01:02 GMT

If someone has any idea on how to deal with this problem, it would be really helpful ! Thanks you a lot.

(If anybody speeks french this topic deals with the same issue : )