Hi,

In the proof of concept project we have now moved the ASPXToPDF to our test web farm.
The binding is https.
As expected the url address is not working and I have read your documentation about troubleshooting ASPXToPDF.

At the moment it is a 2003 server, but it will soon be moved to a 2012 server.
Do you have any recommendation/worked on it on how to set up the DNS mappings on server in the web farm.
We need to hit the same server in the web farm as the original call.
Will the insert of dns mapping in the host file on each server solve the problem.
I need to check with the infrastructure team if it is possible to do.

I got an exception on the RenderToPDF since the url address didn't exist.
The url address was not an https, it was an http like this.

Original address.
https://test.xxxx.xxx/Default.aspx

The address returned in the exception when calling RenderToPDF.
http://test.xxxx.xxx/Default.aspx
Perhaps you know the reason for that.

Best Regards
Ole Oscar

Hi,

You do not have to add an entry to map to the external host name to your local IP. The root of the problem is a Url can not be loaded on your server. We don't care what DNS entry you have. But the HTML to PDF converter must be able to load the dependency resource on your server. Consider that you try to convert the following HTML:



The converter goes through the following steps in order to render this image. Note that all steps occurs on your web server:

1. Take the current page Url from HttpContext.Current.Request.Url. So if your original address is https://test.xxx.xxx/Default.aspx but somehow the converter sees http://test.xxx.xxx/Default.aspx, then you will want to check your HttpContext.Current.Request.Url first. If that property gives you https, then there is no reason we get http;

2. Take the base Url from your current page Url. For example, if the page Url is http://test.xxx.xxx/Default.aspx, then baseUrl is http://test.xxx.xxx;

3. Set HtmlToPdf.Options.BaseUrl to the base Url value acquired in step 2;

4. Call BeforeRender event. You can change HtmlToPdf.Options.BaseUrl in this step. For example, if you have a DNS issue and you do not want to address that, you can change your BaseUrl to IP form in this case;

5. The converter uses the base Url to expand the partial Url to a full Url. For example, if you did not change BaseUrl in step 4, then the full Url for the image would be "http://test.xxx.xxx/logo.gif";

6. Use the full Url in step 5 to load the resource. We don't care how you fix your DNS or network or server, as soon as the Url on step 5 can be used to load the image then it will work. If that Url fails, then the converter fails;

Hope this gives you enough insight to resolve the issue.

Thanks!

Hi,

The main page Url has nothing to do with ASPXToPDF except that ASPXToPDF uses it to derive BaseUrl. ASPXToPDF works by intercepting the ASP.NET output for the page and then pass the result HTML to HtmlToPdf.ConvertHtml. So it does not issue a request to your web server for the main page. It only requests the dependencies from your web server. The main page request is the request from your client computer browser to your web server, this request triggers ASPXToPDF, in another word, the main request is already done before the converter starts.

Thanks

Hi,

This is something you will need to fix on your load balancer/Web server. The request has to reach our converter promptly. The converter does not make up the http://test.xxx.xxx/Default.aspx Url itself. So it has to be coming from your web server. As we have already explained in our early post, we take the url from HttpContext.Request.Url. As such that's what you need to fix first.

Thanks

Hi,

Unfortunately no. By the time you get HtmlToPdfResult, the conversion is already done and the original HTML is already discarded. However if you just want to check the HTML, you can check it with a network package monitor and that should be able to show you everything that traveled through your network between your browser and your server.

In your case, I think you should focus on the difference between the Urls. Specifically, why when you type in "https://test.xxxx.xxx/Default.aspx" in your browser, but when it gets to your server it becomes "http://test.xxxx.xxx/Default.aspx". As we have already explained to you earlier, we get the current Url through HttpContext.Current.Request.Url. So your question should be why "https" becomes "http" when it reaches your server. This should not have anything to do with us, you should be able to reproduce this problem without using our DLL at all.

This is why it appears that you are looking at the wrong direction that you are trying to check the HTML. The root of the problem seems to be that BaseUrl is wrong so that's what you need to fix. Specifically, you need to do either of these three things:

1. Change your network/load balancer configuration to make sure your application sees HttpContext.Current.Request.Url as "https" instead of "http" since you already know that the "http" Url does not work (based on your " requested url, <http://test.xxxx.xxx/Default.aspx>, could not be found" error message);

--- OR ---

2. Override HtmlToPdf.Options.BaseUrl in your code inside BeforeRender event. See step #4 in our original reply.

--- OR ---

3. Make sure the http Url works. That is, to fix your configuration so that if you type "http://test.xxxx.xxx/Default.aspx" in a browser directly on the server and it works fine. Current this does not work;

Option 1 and option 2 allows you to stick with https, where options 3 stick with http and make http work on your web server. Either of the above should fix the problem for you. So HTML probably should not be the focus for you.

This does not appear to have anything to do with DNN. It looks much more like a simple server configuration issue.

Hope this makes sense to you and help you resolve the issue.

Thanks!

Hi,

You might want to consider option 2 and option 3 in our previous reply. You do not have to wait for anybody in order to use option 2. Option 3 you will need your server/infrastructure team to make the change for you. Option 1 could be the hardest because if that's how your server works now then your infrastructure team must have a reason to do it that way. In any case, this is a configuration issue that you need to address on your side.

Thanks!