We have been using ABCpdf for years now. In fact we are on version 6.1 still. It has just always worked. But we have recently upgraded to Windows 2008 x64 / IIS 7.5.
Our code that converts HTML pages (Invoices) to PDF now does not work. The basics are that there is a QueryString based URL that renders the Invoice in HTML, this allows us to "preview" it, then to send it to the client we use ASP .NET to execute the ABCpdf code (calling that same URL from the server to the server). This time the output is PDF, and that's what is attached to an email and sent off to the client.
Pretty simple and straight forward stuff right?
This is what we noticed about ABCpdf:
1) PdfObj.AddImageUrl("http://localhost/..."); // Localhost does not work.
2) PdfObj.AddImageUrl("http://127.0.0.1/..."); // Local IP does not work.
3) PdfObj.AddImageUrl("http://41.XX.XX.XX/..."); // Live IP does not work.
Now this:
4) PdfObj.AddImageUrl("http://www.google.com/"); // Works perfectly!
So we know the code and everything about it technically can and does work.
But it seems that any time the AddImageUrl() function calls a location that points to itself, the page does not render and we get "Unable to render HTML. Page load timed out. Unable to load page."
I know it's not to do with the timeout because if I use Fiddler (on the server) to execute the exact same code, it works perfectly.
I suspect this is to do with permissions... what what permissions? I read this: "... this is because ABCpdf uses the Microsoft MSHTML component" but how do I set the permissions on this component. I have already turned off "IE ESC".
What am I missing?
So it turned out after fiddling with just about every setting, that it came down to the fact that IIS did not allow URL calls from w3wp.exe to the same "site" within the same IIS.
There is more on that here: http://support.microsoft.com/kb/316451
It wasn't the "MSXML2.ServerXMLHTTP.3.0" requests, these seems to work - and why it was so confusing. But in ABC PDF, there is obviously something similar, and so IIS was blocking it... in fact the entire "site" locked up while it was failing.
In the end all it took was to make a clone of the main site ("site2"), and changing the URL that was parsed to ABC pdf to use the clone site.
Related
IIS7 serving .Net web application (simple database site).
I have a weird issue where the backgroundimage(URL) property of a element will be served as "http:\localhost" instead of "http:\servername". This is a problem because when a user connects to my site, "localhost" would be their workstation, not the IIS server. So the image (in this case a button) is blank.
The issue is intermittent, recycling the application pool seems to fix the issue for a time and then it comes back. IIS server also runs a SQL instance which eats ~28/36GB RAM.
Anyone ever seen anything like this?
In order to fix this you need to search for all locations where "http:\localhost" is hardcoded in your web app and replace it with a dynamic path. Even though localhost can work in your code if it is relative to the server, there are times when it will not work, such as in a link. You should get in the habit of never hardcoding your urls.
If you are using MVC -
value = Url.Content("~/Images/MyImage.png");
If you are using Forms -
value = ResolveUrl("~/") + "Images/MyImage.png"
Or relative pathing -
value = "~/Images/MyImage.png"
We recently updated a CRM 2011 on premise instance to use SSL i.e. https. I wasn't involved in the server part of the updates. Everything works fine except at initial login, IE displays the "Only secure content is displayed" warning. If I look at the source of the page, I see a bunch of http://... refs to microsoft sites for example. So presumably that is the source of the issue. The landing page doesn't have any custom "stuff" on it, all OOTB.
What can we do to get around this? I know we could change an IE setting but that isn't an option for us. Is there some IIS voodoo tthat we can use? Surely we don't have to go through all http refs in the web app and change them?
I know we could change an IE setting but that isn't an option for us. Is there some IIS voodoo tthat we can use?
Man, I wish. Even when we get HTML e-mails with images in them we get that message.
Because it's a security setting and it's the browser causing the error message and not the server, there really isn't much we can do about it on the server side except for serving all content over SSL.
That being said, it seems really strange that out of the box content is giving you errors.
It's possible that using a re-write rule on IIS will stop this from happening, as all the content on your server is capable of being served in SSL, but CRM is not requesting it - I'm just hoping that this doesn't break any customization and links to external services.
I had created a simple portal site for our internal users, just a CSS menu with our internal web services which then displayed in an iFrame. Worked well so far.
Our helpdesk software was GLPI running on APACHE on the same server and had no issues. We recently upgraded to the latest version and in the meantime I moved it to our new web apps server and switched to IIS. The 'portal' is still hosted on the old server.
When I updated the javascript for the iFrame to point to the new address, it looked like it worked, I could get the login screen for GLPI. After logging in however I just get stuck at a white screen. If I try it in IE I get the message:
This content cannot be displayed in a frame
To help protect the security of information you enter into this website, the publisher of this content does not allow it to be
displayed in a frame.
What you can try:
Open this content in a new window
It doesn't seem to be the iFrame itself as I can get the login page.
My question is, can anyone give me some ideas on where to look at this issue? I've checked the IIS logs on both sides and see no errors, GLPI reports no errors, neither does PHP.
GLPI is on IIS 8 on Server 2012
The 'portal' is on IIS 6 on server 2003
GLPI running on PHP 5.3.0
EDIT: I've looked into the X-FRAME issue and I'm pretty sure this is not it, servers are on the same domain and I am able to get to the login screen of the second server through the iFrame, just no content after that. If it was an issue with the frame or permissions I would expect to not get to the site at all?
The only header response currently in IIS is 'X-Powered-By --> ASP.NET' am I looking in the wrong spot?
The server is returning an X-Frame-Options header used to prevent ClickJacking. That header must be removed (or updated with an Allow-From directive that lists the framing page's origin) in order for the target page to be rendered as a subframe.
I got an issue when using HttpContext.RewritePath in HttpModule for URL rewriting.
Environment: Windows Server 2008 R2, IIS 7.5 integrated mode, .Net 4.0
In my project, most URLs will be rewritten to the same aspx page(Handler.aspx). The aspx page will do different thing based on the URL.
Example:
"/en/abc/" will be written to Handler.aspx. [Page output: This is abc]
"/en/test/" will be written to Handler.aspx. [Page output: This is test]
"/en/test/a.html" will be written to Handler.aspx as well. [Page output: This is test]. As I only check the string "test" and ignore the sting "/a.html", the output is same as the URL "/en/test/". And a.html doesn't exist in wwwroot folder, the URL is a bad case for testing.
I got a issue, if 2 or more requests that contain htm/html extension come simultaneously
Example: "/en/test/a.htm" or "/en/test/a.html"
HttpContext.RewritePath will not work for any request after that. Handler.aspx won't be called any more, and the page output will always be 'This is test' no matter what URL entered. Http status code is 200 when the issue occurs. Also if visit the real aspx page(Handler.aspx), it will display the same content 'This is test' as well. It seems like a server-side cache. And this issue can be resolved by recycling app pool in IIS.
In following cases, the issue won't occur:
Visit these two requests with a delay, for example visit "/en/test/a.html" first and wait 3-5 seconds, then visit "en/test/a.html" again. Everything works fine.
Change IIS pipeline from integrated mode to classic mode. If visit "/en/test/a.html", a IIS 404 page will be displayed.
Use Server.Transfer instead of HttpContext.RewritePath, everything works fine.
The URL contains .php, .jsp, .xml won't cause the issue
I have to find the root cause of it. Any potential reason may cause this issue?
I have a web application which works fine when i publish and host it on my localhost ...
The same published folder i host to a remote server and a few controls go missing on load of the page .I log into remote desktop to the server and try opening the site on the server itself it works fine. But only when i access it from my local system some controls go missing .Is there something i am missing on the Browserused on the swerver as well as my local system is IE 8 .
Thanks & Regards,
Francis P.
You probably have some URLs with a hard-coded http://localhost/....
Change all of your absolute URLs to relative URLs.
Fiddler and Firebug will be very helpful to see which URLs are being requested.