Azure blob hosted XOD: "Error loading document: Invalid XOD file: Zip end header data is wrong size"

718 views
Skip to first unread message

Chris Hine

unread,
Dec 9, 2014, 9:36:37 AM12/9/14
to pdfnet-w...@googlegroups.com
We're hosting a XOD on Azure blob storage and after it is downloaded by the WebViewer an error is generated from within CoreControls.js:

Uncaught Error: Error loading document: Invalid XOD file: Zip end header data is wrong size!

It is unclear what the problem might be, any help would be appreciated.

Request:

GET /00000001/1.xod?sv=2014-02-14&sr=c&sig=weWc6lK76UgmOk0lNub8BAq7FP%2FgOeijUcrw7oalh%2Bk%3D&se=2014-12-09T14%3A28%3A06Z&sp=r&_=-22, HTTP/1.1
Host: kaizenqa.blob.core.windows.net
Connection: keep-alive
Origin: http://localhost:9001
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36
Accept: */*
Referer: http://localhost:9001/PDFTron/html5/ReaderControl.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Range: bytes=-22

Response:

HTTP/1.1 200 OK
Content-Length: 5244158
Content-Type: application/octet-stream
Content-MD5: zep5efai9xCnWcZrIcR6Iw==
Last-Modified: Tue, 02 Dec 2014 19:13:22 GMT
Accept-Ranges: bytes
ETag: "0x8D1DC7B2C9C9325"
Vary: Origin
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 59e9eccb-0001-001b-766e-042142000000
x-ms-version: 2014-02-14
x-ms-lease-status: unlocked
x-ms-lease-state: available
x-ms-blob-type: BlockBlob
Access-Control-Allow-Origin: http://localhost:9001
Access-Control-Allow-Credentials: true
Date: Tue, 09 Dec 2014 13:38:06 GMT

Matt Parizeau

unread,
Dec 9, 2014, 6:26:55 PM12/9/14
to pdfnet-w...@googlegroups.com
Hi Chris,

So it seems like Azure blob URLs don't support range requests of the form "-endByte" like WebViewer is doing here with Range header "bytes=-22" to grab the last 22 bytes. See here for more information http://msdn.microsoft.com/en-us/library/azure/ee691967.aspx

It's a bit strange that Azure doesn't support this, however we've added a workaround that should get this to work with Azure at the cost of an extra HTTP request. You can download a build with this update here: http://pdftron.com/ID-zJWLuhTffd3c/WebViewer/WebViewer_1.8.1.28499.zip

Once you've done this you'll have to make one small change to ReaderControl.js. Find the loadDocument function and change HttpPartRetriever to AzurePartRetriever. This part retriever uses the workaround and will also continue to work with XOD documents loaded from other locations as well.

Matt Parizeau
Software Developer
PDFTron Systems Inc.

Chris Hine

unread,
Dec 10, 2014, 4:57:40 PM12/10/14
to pdfnet-w...@googlegroups.com
Thanks, this is helpful.

I can see it receiving a 206 response from Azure now. Now we're hit upon CORS being a issue. As soon as we get the xdomain proxy set up we'll (hopefully) finally see it working.

Is it intended that there will be a future build which doesn't require such an alteration of the library?

Chris

Matt Parizeau

unread,
Dec 10, 2014, 7:24:02 PM12/10/14
to pdfnet-w...@googlegroups.com
Hi Chris,

We'll consider adding it as an option you can pass to the WebViewer constructor.

Matt Parizeau
Software Developer
PDFTron Systems Inc.
Reply all
Reply to author
Forward
0 new messages