<base href pointing to a URL for the base does not get handled correctly

[Dave]

| it sounds like you are setting <base> as a url. What ini setting do you have for allow_url_fopen? Unlike viewing the html in a browser, where the css is opened by a browser, here the css file is loaded by dompdf. Can 

| you set the <base> to a the local directory?

| John

At the request of John I'm splitting off the original thread so this one will more accurately describe the issue (original thread is https://groups.google.com/forum/?fromgroups#!topic/dompdf/-zoB5jYpkfs).

The <base> is in fact a URL and allow_url_fopen is set to on John.  This is being done with an exisiting ecommerce solution and change <base> is not an option I'm afraid.

Is there any additional debugging I can do to try and determine why it isn't working for me?  FWIW the URL in the samples I've posted about this point to a local only URL which does get resolved correctly by DNS so opening the URL should work just fine (it does using cURL).

Dave

[John Bell]

I'm not sure what you mean by 'local only url'. The url needs to be
resolvable by the server.

I'm not sure if it will solve your issue, but there is an old proposal
to use curl.
http://code.google.com/p/dompdf/issues/detail?id=69&colspec=ID%20Type%20Status%20Stars%20Priority%20Milestone%20Owner%20Summary%20Modified
<http://code.google.com/p/dompdf/issues/detail?id=69&colspec=ID%20Type%20Status%20Stars%20Priority%20Milestone%20Owner%20Summary%20Modified>

John

On 29/04/2012 13:49, Dave wrote:
> | it sounds like you are setting <base> as a url. What ini setting do
> you have for allow_url_fopen? Unlike viewing the html in a browser,
> where the css is opened by a browser, here the css file is loaded by
> dompdf. Can
> | you set the <base> to a the local directory?
>
> | John
>
> At the request of John I'm splitting off the original thread so this
> one will more accurately describe the issue (original thread is
> https://groups.google.com/forum/?fromgroups#!topic/dompdf/-zoB5jYpkfs

> <https://groups.google.com/forum/?fromgroups#%21topic/dompdf/-zoB5jYpkfs>).

>
> The <base> is in fact a URL and allow_url_fopen is set to on John.
> This is being done with an exisiting ecommerce solution and change
> <base> is not an option I'm afraid.
>
> Is there any additional debugging I can do to try and determine why it
> isn't working for me? FWIW the URL in the samples I've posted about
> this point to a local only URL which does get resolved correctly by
> DNS so opening the URL should work just fine (it does using cURL).
>
> Dave

> --
> You received this message because you are subscribed to the Google
> Groups "dompdf" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/dompdf/-/pkgZuLPC4tQJ.
> To post to this group, send email to dom...@googlegroups.com.
> To unsubscribe from this group, send email to
> dompdf+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dompdf?hl=en.

[Dave]

On Sunday, April 29, 2012 8:57:47 AM UTC-4, John Bell wrote:

I'm not sure what you mean by 'local only url'. The url needs to be
resolvable by the server.

It is able to be resolved by the server (it may be reached with a browser).

 

I'm not sure if it will solve your issue, but there is an old proposal to use curl.

Well given the fact that allow_url_fopen is enabled and things aren't working I'd love to be able to try cURL. That proposal looks to be almost 3 years old and from what I can gather the allow_url_fopen direction won over the use of cURL.

Still wish there was more debugging I could do to try and figure out why it isn't working as everyone says it should be.

Dave

[John Bell]

>It is able to be resolved by the server (it may be reached with a browser).

... not quite the same thing. Do you have shell access to the server? if so what do you get if you type:
wget http://<your style file url>
?

John

--
You received this message because you are subscribed to the Google Groups "dompdf" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dompdf/-/__CPIrobjF8J.

[Dave]

On Monday, April 30, 2012 9:05:51 AM UTC-4, John Bell wrote:

>It is able to be resolved by the server (it may be reached with a browser).

... not quite the same thing.

How is not the same?  Both methods rely on DNS to resolve the name to an IP address no?

 

Do you have shell access to the server?

It's a Windows box.

 

if so what do you get if you type:
wget http://<your style file url>

It retrieves the style file without error and reports a 200 response which I expected.

Dave

[BrianS]

Are you still having trouble with this? I've tested using a similar setup on my own server and it renders correctly. It should no longer be necessary for CSS, but do you have DOMPDF_ENABLE_REMOTE set to true? Does your server have read/write access to the directory specified by DOMPDF_TEMP_DIR? If you enable PHP errors (preferably via error logging) do you see any errors or warnings?

[Dave]

On Monday, May 14, 2012 10:32:05 PM UTC-4, BrianS wrote:

Are you still having trouble with this?

Yes

 

I've tested using a similar setup on my own server and it renders correctly. It should no longer be necessary for CSS, but do you have DOMPDF_ENABLE_REMOTE set to true?

Yes

 

Does your server have read/write access to the directory specified by DOMPDF_TEMP_DIR?

Yes

 

If you enable PHP errors (preferably via error logging) do you see any errors or warnings?

None

 

Dave

[BrianS]

Frustrating I'm sure. It's sometimes hard for us to debug these kinds of problems when we're just throwing things at the wall and waiting for a report back.

Just to confirm, you downloaded a fresh copy of the code after Fabien implemented support for that feature, correct?

So let's try and get a little creative with our debugging. First let's see what happens when dompdf is taken out of the equation. Can you create a simple file that's something like the following:

<?php
echo file_get_contents('http://devus711.mtnlan.com/skins/Default/css/all.css');
?>

Simple. It should return your stylesheet of course.

[BrianS]

Frustrating I'm sure. It's sometimes hard for us to debug these kinds of problems when we're just throwing things at the wall and waiting for a report back.

Just to confirm, you downloaded a fresh copy of the code after Fabien implemented support for that feature, correct?

So let's try and get a little creative with our debugging. First let's see what happens when dompdf is taken out of the equation. Can you create a simple file that's something like the following:

<?php
echo file_get_contents('http://devus711.mtnlan.com/skins/Default/css/all.css');
?>

Simple. It should return your stylesheet of course.



On Tuesday, May 15, 2012 6:05:57 AM UTC-4, Dave wrote:

[A Kareem]

Thank you guys,

Problem is solved.


Cheers,

Imran

--

You received this message because you are subscribed to the Google Groups "dompdf" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dompdf/-/OMmDz_cI0pAJ.

[BrianS]

Glad to know! Was it an issue with dompdf or did you discover the problem elsewhere?

On Tuesday, May 15, 2012 1:08:09 PM UTC-4, A Kareem wrote:

Thank you guys,

Problem is solved.


Cheers,

Imran