Internet Explorer 10

105 views
Skip to first unread message

Marko Jovanovic

unread,
Oct 21, 2014, 10:57:46 AM10/21/14
to pdfnet-w...@googlegroups.com
Hi Matt,

We are using PdfTron component version 1.8.0 to display materials to our site users. We host xod files on our server, those are pdf docuemnts converted to xods. 

One of our users had issue yesterday. User reported that he was not able to see materials. By inspecting server logs I found that user was using IE10 and strange thinng was that log file has column for received bytes value around 7MB which corresponds to the document original xod size. We have customized webviewer and we use option streaming: flase so webviewer should be using byte-range requests instead of downloading whole file. As far as I know IE10 should support this feature. This is strange also as no other user reported such issue and I was not able to reproduce the issue too. 

Do you have any suggestion what might be causing the issue or to point us what should we check. 

Thanks,
Marko

Matt Parizeau

unread,
Oct 21, 2014, 7:27:27 PM10/21/14
to pdfnet-w...@googlegroups.com
Hi Marko,

You're right that is strange as IE10 does support byte ranges. The only thing I can think of is that WebViewer will do a test for range requests by making a request to the page's html file and if that request returns 200 (instead of 206) or fails then it will revert to using non-range requests. So maybe the first range request to the html page failed for some reason but then the request for the document immediately after was successful and it was downloaded completely. However in this case the document should still be shown though it will be less responsive. Other than that unfortunately I'm not sure unless you have more information.

Matt Parizeau
Software Developer
PDFTron Systems Inc.

Gisa Jovanovic

unread,
Oct 22, 2014, 12:28:09 PM10/22/14
to PDFTron WebViewer on behalf of Matt Parizeau
Thank you for the info and on quick response Matt,

You are right about html page response, it is 200 instead of 206 which occurs with all other users. We had another user yesterday with same thing happened. User was using IE10 and also Chrome version 26, a bit deprecated version, with same response 200 and also with cs-uri-query value -22 this time (value that suggest xod file is missing). With previous user there was no -22 value for cs-uri-query but still according to user material did not displayed. 

Can you point to what to investigate in terms of 200 response. I will also try to reproduce issue locally and try to provide you with sample.

Thanks,
Marko  



--
You received this message because you are subscribed to the Google Groups "PDFTron WebViewer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdfnet-webview...@googlegroups.com.
To post to this group, send email to pdfnet-w...@googlegroups.com.
Visit this group at http://groups.google.com/group/pdfnet-webviewer.
For more options, visit https://groups.google.com/d/optout.



--
Pozdrav, Giša Jovanović
Nova Com
Carice Teodore 26
Niška Banja
018 45 49 701
062 360 750
rex...@gmail.com
www.rexx.rs

ODRICANJE OD ODGOVORNOSTI

Informacija u ovom e-mailu namenjena je isključivo primaocima navedenim u adresi poruke. Poruka može sadržati poverljive informacije. Ukoliko greškom primite ovaj e-mail, molimo da ga obrišete. Ako niste navedeni kao primalac, svako kopiranje, korišćenje i obelodanjivanje sadržaja je zabranjeno i može biti nezakonito. NovaCom nije odgovorna, niti garantuje, za bilo koje mišljenje, preporuku, zaključak, zahtev, ponudu i/ili ugovornu obavezu koja se ostvaruje ovakvim načinom komunikacije.

DISCLAIMER

Information in this email is intended for the recipients addressed in the email. It may contain confidential information. If you receive this email in error, please delete it. If you are not addressed as the recipient, please have in mind that copying and disclosure of the email or using the information contained in the email is prohibited and may be unlawful. NovaCom neither endorses nor is responsible for any opinion, recommendation, conclusion, demand, offer and/or agreement contained in this email.



Matt Parizeau

unread,
Oct 22, 2014, 8:28:51 PM10/22/14
to pdfnet-w...@googlegroups.com
Hi Marko,

The query value -22 is the first range request that WebViewer will make on the document after the initial test request to the html page. It gets the last 22 bytes of the file which has information about the byte offsets to parts in the document. So it would make sense that -22 would show up but I'm not sure why everything failed after that.

One thing you could try is to force a fake 200 response initially so that WebViewer switches to the non-range request mode and then see if anything is shown. You can do this by modifying ControlUtils.js. Find the byteRangeCheck function and in the success callback change it to onSuccess(200); 

Matt Parizeau
Software Developer
PDFTron Systems Inc.


On Wednesday, October 22, 2014 9:28:09 AM UTC-7, Marko Jovanovic wrote:
Thank you for the info and on quick response Matt,

You are right about html page response, it is 200 instead of 206 which occurs with all other users. We had another user yesterday with same thing happened. User was using IE10 and also Chrome version 26, a bit deprecated version, with same response 200 and also with cs-uri-query value -22 this time (value that suggest xod file is missing). With previous user there was no -22 value for cs-uri-query but still according to user material did not displayed. 

Can you point to what to investigate in terms of 200 response. I will also try to reproduce issue locally and try to provide you with sample.

Thanks,
Marko  


On Wed, Oct 22, 2014 at 1:27 AM, Matt Parizeau via PDFTron WebViewer <pdfnet-webviewer+noreply-APn2wQfzwjN3K1PXhwB2EpteOBUOrXzBt3...@googlegroups.com> wrote:
Hi Marko,

You're right that is strange as IE10 does support byte ranges. The only thing I can think of is that WebViewer will do a test for range requests by making a request to the page's html file and if that request returns 200 (instead of 206) or fails then it will revert to using non-range requests. So maybe the first range request to the html page failed for some reason but then the request for the document immediately after was successful and it was downloaded completely. However in this case the document should still be shown though it will be less responsive. Other than that unfortunately I'm not sure unless you have more information.

Matt Parizeau
Software Developer
PDFTron Systems Inc.


On Tuesday, October 21, 2014 7:57:46 AM UTC-7, Marko Jovanovic wrote:
Hi Matt,

We are using PdfTron component version 1.8.0 to display materials to our site users. We host xod files on our server, those are pdf docuemnts converted to xods. 

One of our users had issue yesterday. User reported that he was not able to see materials. By inspecting server logs I found that user was using IE10 and strange thinng was that log file has column for received bytes value around 7MB which corresponds to the document original xod size. We have customized webviewer and we use option streaming: flase so webviewer should be using byte-range requests instead of downloading whole file. As far as I know IE10 should support this feature. This is strange also as no other user reported such issue and I was not able to reproduce the issue too. 

Do you have any suggestion what might be causing the issue or to point us what should we check. 

Thanks,
Marko

--
You received this message because you are subscribed to the Google Groups "PDFTron WebViewer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdfnet-webviewer+unsubscribe@googlegroups.com.
To post to this group, send email to pdfnet-webviewer@googlegroups.com.

Gisa Jovanovic

unread,
Nov 19, 2014, 1:25:43 PM11/19/14
to PDFTron WebViewer on behalf of Matt Parizeau
Hi Matt,

thank you for your reply. 

Regarding your comments yes your are right, column G is query parameter column. I think there is no option to log range header.

One thing to note, results you saw were collected using modified ControlUtil.js byteRangeCheck function:

//onSuccess(jqXHR.status);
onSuccess(206);

so from first image results are maybe caused by that change, although in my logic this change should instruct ReaderControl to use HttpPartRetriever instead of StreamingPartRetriever, hence even if server response is 200 it should use HttpPartRetriever. Not sure if this is correct though, on the other hand result suggest that even though query had been set server had chosen to repond with 200.
 
Since yesterday I have reverted all changes I made and again code is exactly as in webviewer 1.7.1 build. 

Not sure if server settings has to do with it or hosting network settings or even perhaps users network settings (maybe in case of proxy)...

As of today with default webviewer 1.7.1 version settings there was one such occurence with 200 response but no range header set. I could see whole document was downloaded based on bytes sent. Not sure if user had issues though, at least I am not aware of user reporting it as for today.

Thanks on your response, if you have any suggestion how to test or what else I could try please let me know.

Sincerely,
Marko





On Wed, Nov 19, 2014 at 2:08 AM, Matt Parizeau <mpar...@pdftron.com> wrote:
Hi Marko,

In the first screenshot according to the query parameters it looks like all of the requests were sent with ranges, so I don't know why the server responded with a 200 response. I can only think of two reasons:
1. There is a bug in the server where it will respond with a 200 response incorrectly.
2. There is a bug in WebViewer where it sets the query parameters but doesn't set the Range header on the request. Is it possible to log the value of the Range header on the requests?

For the second screenshot is the "G" column the query parameter? It looks like for the XOD requests it is not making range requests because it isn't setting the query parameter. Again it would nice if I could see the value of the Range header since doesn't necessarily equal the query parameter (though it should). In this screenshot it seems like the request to ReaderControl.html is returning 200 which is possibly why it falls back to streaming. Maybe the user was looking at a cached version of your page and didn't have the change where you forced it to switch to the non-streaming?

So basically I would be interested in seeing the value of the Range header for those requests and that might help figure out where the issue is occurring.

Matt Parizeau

Software Developer

PDFTron Systems Inc.


On Tue, Nov 18, 2014 at 1:54 PM, Marko Jovanovic <rex...@gmail.com> wrote:
Hi Matt,

one note, I mentioned that we are using webviewer version 1.8 but in fact we are using webviewer 1.7.1 version.

Best Regards,
Marko
To unsubscribe from this group and stop receiving emails from it, send an email to pdfnet-webview...@googlegroups.com.
To post to this group, send email to pdfnet-w...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages