Re: Stream() method hangs with IE (ok with FF)

[BrianS]

Is the client sending data to dompdf, or is this completely server-side? No other notices/warning from PHP? What happens if you set $_dompdf_show_warnings to true?


On Monday, April 29, 2013 5:35:37 PM UTC-4, Frédéric Barboteu wrote:

Hi,

Using stream() method of dompdf 0.6.0 b3 with PHP 5.4.6 and Windows 7, I get:
>> the expected result (correct file), with FF 20.0.1
>> an infinite loop with IE10

When max_execution_time is reached, the error message I get points dompdf/include/functions.inc.php at line 762, which is record_warnings() function begin.
Without any other information, I can't figure out what is happening...

Thanks in advance for any comment.

[Frédéric Barboteu]

Thanks for the response.

Yes, this is completely server-side. Here is the code, pretty simple:
<?php
include(@$_REQUEST['se_dompdf'].'/dompdf_config.inc.php');
if($se_pdf_tmp=@$_REQUEST['se_pdf_tmp']) {
  # get source HTML file and drop it:
  $html=file_get_contents($se_pdf_tmp);
  unlink($se_pdf_tmp);
  # create PDF file:
  global $_dompdf_show_warnings; ##
  $_dompdf_show_warnings=true; ##
  $dompdf=new DOMPDF();
  $dompdf->load_html($html);
  $dompdf->render();
  # stream the PDF to the client (will open a download dialog by default):
  $dompdf->stream(@$_REQUEST['se_pdf_name'].'.pdf');
}
?>

You can see that I tried to set $_dompdf_show_warnings to true, as you suggested. Now the result is:
>> with FF: echoes "Unable to stream pdf: headers already sent"... seems to be normal, no?
>> with IE: the same as before setting $_dompdf_show_warnings to true: infinite loop, without any echo

Thanks for your effort.

[BrianS]

What warnings do you get? I think, by default, they're recorded in dompdf/lib/fonts/log.htm

The code does look pretty straightforward. Have you tried testing the various parts. Easiest method is to echo out the variables after they're set and then exit(). That way you can check that the code is doing what you expect.

For example, you might echo out the value of the $html variable after setting it. Then after loading it into dompdf, you might echo $dompdf->output_html() to see the HTML that dompdf is working with. And if you take out the call to $dompdf->stream(), or does it even get that far with IE?
-b

[Frédéric Barboteu]

Thanks for these advices, especially for inserting echoes... I should have think to that by myself!

Warnings in dompdf/lib/fonts/log.htm don't show anything interesting, since log.html is not set with IE.
Secondly, $dompdf->output_html() shows pretty results both with FF and IE, after $dompdf->load_html().
In the other hand, it appears that the infinite loop with IE happens during execution of $dompdf->render(), since a simple "echo 'bar'"; after this line never outputs.

Now I can't figure out how to explore it deeper: could you point me to the right doc?
Thanks in advance.

[BrianS]

render() is where the majority of what dompdf does happens so it's a bit difficult to give you many pointers on debugging it. If you replace your current load_html() with something simpler, like $dompdf->load_html('hello world'), does IE work better?

Also, is your site accessible online somewhere so we can do a few tests?

[Frédéric Barboteu]

Sorry to be late...

Yes, the site exists also online, but it is on Linux, and there it works both with FF and IE: the problem happens only with IE on Windows (my local system)!

I tried to load a simple string into load_html(), as you suggested: it works.
Then I guessed that the real HTML content proposed to render() might be corrupted in some manner (it is live built under JS in a precedent step, so IE could generate it differently than FF does).
So I first modified my code to save this content just generated, and compare IE and FF versions built from the same source sample.
They differ only by 2 little points : 1. some attributes appear in a different order inside some HTML elements; 2. IE drops spaces after semi-colon in some style-attribute sequences.
Not something which could cause it to fail, nevertheless I then tried to submit to IE the content originally built by FF: keeps failing.

I also tried to use previous versions of IE, which led me to an interesting observation.
Note that I only have IE10 available, so due to the fact that the guilty page is generated as Nth step in my process, in order to switch to another version I had to:
. first kill the current page (clicking the red cross) before reaching the max_execution_time
. then go to the IE10 "F12" window and choose another IE version
. finally go back to my page and type F5
Anyway, keeps failing with IE9, IE8...

But now is the interesting thing: switching doesn't immediately responds, but only after a number of seconds, and... then IE displays the expected download dialogbox!
Obviously the generated PDF file is declared corrupted by Adobe Reader.
But from this my guess is: seems to mean that dompdf->render() has done a (very little) part of its job, so we could think that the "infinite" loop is rather the fact that, for some reason, it takes a long long time to work.

What do you think?
Thanks in advance.

[BrianS]

So the PDF is downloaded after switching rendering modes in IE. It could just be a fluke and maybe the page is re-rendering after switching rendering modes. But ... if you are able to download the PDF then there might be useful information inside the document. Typically with dompdf when a PDF reader complains about the document being corrupted it is because some PHP errors were pushed into the output stream. If you open the PDF in a text editor (Notepad, for example) you may see some PHP warnings at the top of the page.

FYI, the reason you're seeing a delay from the server could be because of the PHP timeout. This is a gross oversimplification, but let me elaborate. The script that was running when you switched rendering modes in IE is likely still running on the server. Some web servers tie a user to a particular child process. So when IE switches rendering modes and the page reloads the web server sends it back to the same child process, which is still busy running the previous PHP script. Once that script is done the child process will handle the new request.

We've seen some IE-specific complaints in the past but never had enough evidence to track down the problem. First check the PDF for any PHP errors

[Frédéric Barboteu]

After posting my previous message, I realized I told a stupidity when I said that "render() method might take a long time to work RATHER THAN falling in an infinite loop".
In any case, render() method may ALWAYS work a bit, THEN fall in an infinite loop: so there is no new observation here.

And now, although I agree whith a part of your last assumptions, something now keeps hurting me.
Here is the reflexion steps:
1. AFAIK, script execution on the server cannot be internally influenced by any action from the client, apart from being interrupted
2. whatever the reason why dialog box doesn't appear in usual process (either infinite loop or very long work), it means that the stream() method call has not been reached yet, and process is still inside render() method
3. so, when the browser has been switched and reloads the page, even if it is the same child process, I can't imagine the CURRENT process flow change: it should simply start anew, from its true beginning, and then fall into the same inifinte loop inside render() method, too
4. in the other hand, the previous process is interrupted, but cannot reach the strem() method

So I remain stuck and cannot think depper about this...

In the other hand, I used your suggestion to look at the contents of the PDF generated when switching IE render mode.
Great surprise: this time, it is complete and well rendered by Adobe Reader! May be depending on how quickly I switched...
More and more obscure...

So I decided not to insist to understand: since the public site works, and the problem happens only with my own local (test) server, it will never be a user problem.
Thanks a lot for your comments and your effort.

[BrianS]

Sorry I couldn't help you find a solution, but it is probably best to move on to other things unless the issue begins to affect your production site. If something new comes up feel free to post back to this thread and we can pursue the problem further.

[Frédéric Barboteu]

Don't be sorry, not at all!
In any case you did help me to know more about dompdf.
Thanks anew.

[BrianS]

This was just posted to the issue tracker. I haven't investigated to see how the called-out header affects the browsers, but perhaps it's related to your issue.
https://github.com/dompdf/dompdf/issues/291#issuecomment-17646014

[Frédéric Barboteu]

I must confess I don't understand why you think this post relates to my issue: in my case headers are not concerned, since nothing at all is sent to the browser.

In the other hand, although I said I stopped investigating, I tried other tests :-)
In modified my script in order to use it independantly, and it takes its HTML content from a previously built file.
Then the results are more weird yet!

First, when ending with stream() method, like in the original process:
. IE keeps entering in an infinite loop, as usual
. if I type F5 during this loop execution, it displays a Windows dialog box (not the IE one, which belongs to the navigator window: look at the attached capture)
. choosing "Open" from this dialog box displays the expected PDF content!!

In other words, unlike I seemed through some previous tests, now seems that render() method had finished working, and stream() method should be guilty.
To ensure this, I modified the script to end with output() rather than stream(): yes, it always work.

Also it is worth mention that, as soon as I got the PDF result as explained above:
. typing F5 anew doesn't do anything: the page is not reloaded
. instead, I must go to the url bar and type Enter, which reloads the page, entering in the infinite loop: then F5 displays the dialog-box, etc
Do you think I should ask for help Harry Potter? :-)

Anyway, don't feel obliged to answer this post: it was just to tell the rest of the story...

[BrianS]

On Thursday, May 9, 2013 12:22:08 PM UTC-4, Frédéric Barboteu wrote:

I must confess I don't understand why you think this post relates to my issue: in my case headers are not concerned, since nothing at all is sent to the browser.

I was thinking maybe the headers were finding their way to the browser and that was causing some confusion on the browser's part. What you describe (below) with your new tests may point to this being the case, though really I'm not sure. The fact that reloading shows the PDF could indicate that content was received and cached and that reloading stopped the download process and loaded the cached content.

One way to test this would be to disable the CPDF-determined file size header. You won't get a nice download time estimate, but otherwise it should be fine. And if your server is doing some compression behind-the-scenes there could be a conflict between the stated size and the delivered. Would that cause this kind of problem ... I dunno. But anyway, the test: go into dompdf/lib/class.pdf.php and comment out line 3083 (should be header("Content-Length: " . mb_strlen($tmp, '8bit'));) and see what happens.

It is all very weird and maybe Mr. Potter could help us out a bit.

 

[Frédéric Barboteu]

Oh yes, I see what you think about: I should have realized that, although what I seemed, if the PDF is at least sometimes delivered, it means that dompdf DID work!
From this, and from other tests, I actually conclude that surely dompdf is never concerned, in render() nor in stream() methods.
Let me explain all that make me think so.

First, about IE itself, thanks to a remote job partner I'm sometimes working with, and who accepted to test for me, on its local system (Win7, like me):
. he primarily observed the same "infinite loop"
. then he realized that its IE version was only 9 (yes, we don't like IE very much :-), and updated to IE10: immediately, all worked fine for him!
. in other words, only MY OWN IE10 version fails, and only with MY OWN Apache server (remember: the application works fine with my IE10 on a Linux server)

Second, about IE too:
. in the application, preceding steps include user choices which cause a search process, and leads to invoke the dompdf-concerned page to PDFy the search results
. now I sometimes get IE10 hanging during this search process: kill it and launch anew make it work fine at this step, but the problem randomly appears anew (obviously, this never happens with FF)

Then, about dompdf:
. as you suggested, I tried commenting out the header("Content-length... line in class.pdf.php (BTW, note that for me it is located at line 3071, not 3083): did not change anything
. from your suggestion I had another idea and also tried adding the option 'compress'=>0 in the stream() method: same

Now, about both IE and dompdf:
. looking deeper at the doc, I tried a completely separate test, usig a direct invocation by an url: dompdf.php?input_file=..., and it works fine

So definitely, I consider dompdf is never concerned, and all is due to IE10; more precisely to MY OWN configuration of IE10.
The only thing I plan to do else is to compare the exact version of my IE with my partner's one: I bet they are not same...

This time, really, let us stop investigating this. I'm sorry to have bothered you with it.
Thanks a lot for your effort.

On Friday, May 10, 2013 2:02:30 AM UTC+2, BrianS wrote:

On Thursday, May 9, 2013 12:22:08 PM UTC-4, Frédéric Barboteu wrote:

I must confess I don't understand why you think this post relates to my issue: in my case headers are not concerned, since nothing at all is sent to the browser.

I was thinking maybe the headers were finding their way to the browser and that was causing some confusion on the browser's part. What you describe (below) with your new tests may point to this being the case, though really I'm not sure. The fact that reloading shows the PDF could indicate that content was received and cached and that reloading stopped the download process and loaded the cached content.

One way to test this would be to disable the CPDF-determined file size header. You won't get a nice download time estimate, but otherwise it should be fine. And if , not your server is doing some compression behind-the-scenes there could be a conflict between the stated size and the delivered. Would that cause this kind of problem ... I dunno. But anyway, the test: go into dompdf/lib/class.pdf.php and comment out line 3083 (should be header("Content-Length: " . mb_strlen($tmp, '8bit'));) and see what happens.