I'm getting some odd behavior when my page is loaded in Internet Explorer 11. When my page loads in IE 11 and I watch the Network Tab of the Developer Tools I see a HTTP Get request to the base URL of the page. By base URL I mean the URL without any parameters. This is causing a 500 Internal Server Error to get fired because the Action on the other side of the Request doesn't accept no Parameters. I use Elmah to send me a mail for any unhandled exceptions so whenever a user is using IE I get a ton of Error notifications. This is only happening in IE. Both Firefox and Chrome work as expected. Also, this doesn't seem to break the page in anyway. I only know about this error because of the Emails I'm getting. No User has reported an issue when using IE 11.
Short of searching through every line of Javascript code both 3rd party and my own is there a way in Internet Explorer Developer Tools or even another 3rd party tool that will tell me the exact line (or even js file) that initiated the Http Get Request similar to Chrome's Development Tools?
Here are some images showing the call I'm talking about. The blacked out portion is my API Key.
The original Url being called in the below examples is http://localhost:44301/Grower/Profile/28
The first image is of the Internet Explorer 11 Development Tools with the offending Http Get Request highlighted.
Next is a Fiddler Screenshot of the same request highlighted.
And finally the Chrome Developer Tools showing no such call happening.
I think there's no such a way in IE dev tools to find the initiator line of HTTP request.
But in my research, I find that we can get the file path of the HTTP request initialed using Fiddler. We can find the file path in Inspectors -> Raw -> Referer:
The file path in Referer in Fiddler is exactly the path in Initiator in Network tab in Chrome. So you could try to check the file path using Fiddler.
Related
I have been stuck on this for a couple of weeks now and this is a follow on from SO question Delphi REST Debugger Returns Error 429 Too Many Requests but Browser Returns JSON as Expected
I was wanting to get the content of a url response using the TNetHTTPRequest and TNetHTTPClient components. I was continually getting 429 errors “too many requests”. When using Firefox Inspect Element to look at network and storage, I discovered that I needed to receive cookies and then send those cookies with my request. Unfortunately, one of the cookies essential to the website content seems to be dependent (I think) on the execution of javascript. I went back to first principles and dropped a TWebbrowser on a form (VCL) and sure enough browser shows a javascript error “Expected Identifier”.
When I use the TWebbrowser in FMX it does not throw an error it just does not return the website contents at all and remains blank. I need FMX as I will be in a cross platform mobile environment.
The URL is https://shop.coles.com.au/a/national/home
I use Delphi Community Edition 10.3.3 Rio.
The URL returns perfectly in commercial browsers Firefox, Safari, Chrome and even CEF4Delphi. Unfortunately, I can’t use CEF as I need cross platform.
I would like to know how to get the website content returned to the browser (or even better NetHTTPClient) without script errors and how to access the browsers current cookies.
Any help will be most appreciated.
Thanks,
John.
URL returns perfectly in commercial browsers ... without script errors and how to access the browsers current cookies
If you'd inspect the network traffic (F12 > Network, then requesting your URL) or use uMatrix (to block everything that doesn't belong to the domain by default) you'd see the JS does at least one XHR to amazonaws.com. Your HTTP transfer alone (as done by TNetHTTP*) works fine and you get the same resource that each internet browser gets.
However, you don't operate with what you got (in contrast to the internet browser, which also automatically parses the HTML, sees JS resources, and executes them). TWebbrowser does not what you take for granted most likely due to security settings (try to get an error console in there, preferably F12 again). You need to do the same: parse the HTML resource for JS URIs, requesting those and executing what you get, while still providing the same cookie environment.
For executing JS you could use Chakra or mORMot or BESEN. It's challenging at first, but the more you understand about HTTP (including cookies) and a JS engine, the more you'll see why "things work" in one situation and not in another. There's a reason why an internet browser is a very complex software and not just a downloader.
As per this forcing IE11 Quirks mode might cure your problem already when using TWebBrowser:
TBrowserEmulationAdjuster.SetBrowserEmulationDWORD(TBrowserEmulationAdjuster.IE11_Quirks);
I'm writing an InDesign Extension, InDesign has a embedded chromium (Version 61.0.3163.91) and we're displaying a vaadin website.
Works for previous InDesign CC Versions, but not for the new CC2019. In this version we don't see the content of the page, but this "Caution provisional headers are shown" messages in the debugger.
I can use Chrome as a remote debugger for InDesign so I can see the console, network and more.
In the 'network' I see for every request a Status '200 OK' and the 'Provisional headers are shown' message. I see the correct response and preview for the requests - I do not see the final page.
This is for all request - html, css, javascript, json, images.
I searched stackoverflow for this message and I found some threads and I tried all tipps and ideas in the answers - nothing helped.
When I use the same URL in my chrome browser it works fine. So it may be a problem with this chromium version. Unfortunately I can't just update Chromium because it's embedded in InDesign.
So at the moment I'm out of ideas how to solve this - does anybody has a tipp for me?
I am doing a service call in my javascript which return xml data using xmlHttpRequest.My service call is working in chrome and firefox perfectly and getting the data(it is a https call).But when i try the same with IE11 it is giving status code 12004 .I tried searching it on google i found only one answer saying it means ERROR_INTERNET_INTERNAL_ERROR.
I tried opening fiddler to see the request but when i open up fiddler service call is working fine,but when i close fiddler it is showing same error code.
From the WinINET constant ERROR_INTERNET_INTERNAL_ERROR it appears that the issue is related to the WinINET API which I assume is being used by IE to enable itself to interact with HTTP protocols (including HTTPS) to access Internet resources
http://msdn.microsoft.com/en-us/library/windows/desktop/aa385465(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383630(v=vs.85).aspx
If you really wanted to go deeper and understand the issue, try to download STRACE which is socket/SSL tracer designed to generate LOG for Internet Explorer:
http://www.microsoft.com/en-us/download/details.aspx?id=7643
On a quicker check, you might want to see if your Windows updates is up-to-date to make sure your wininet.dll is the latest and greatest
This one has me stumped.
I have a web app that has a file upload/download area. Files are downloaded in the background via a temporary iFrame element. This is a single-paged AJAX application and the UI is written in Javascript, jQuery and uses the jQuery.FileDownloader.js to manage the iFrame. The application runs over HTTPS and the site and download URL are on the same exact domain. The back-end is a RESTful application. This has worked great for months. Until today.
All of a sudden, when attempting to download a file in Chrome, the browser reports an error of "Blocked a frame with origin https://example.com from accessing a cross-origin frame."
The problem is that the origin of the main site and that of the iframe are the exact same domain. I have ensured that the domains are the same as well as the protocol. Chrome is the only browser that throws up the cross-origin error. IE, Firefox, Opera, Safari... all work as expected. It's only in Chrome and it's only as of today. To make things worse, no updates were made to the browser. It truly is spontaneous. I've also ruled out plugins as the cause by running in Incognito mode, where none are allowed to run by my settings, as well as disabling my anti-virus software. This problem is being exhibited on other computers, in other locations (not on our LAN or subnet), all running Chrome.
And, again, both domains of the parent frame and the embedded iframe are identical. This only happens against the production server which runs over HTTPS. Other non-HTTPS sites (e.g. our dev environment, localhost) don't have the problem. Our SSL is valid. Since this is a single-paged AJAX application, we're trying to avoid popping up another window for the download.
Hopefully, someone can offer some advice. Thanks in advance.
Update: After additional research, I have found the solution to this problem is to enclose the filename in the response header in double-quotes.
I have found the cause of the problem. It turns out that Google Chrome has problems with files that have commas in their filename. When downloading the file via a direct link, Chrome will report that duplicate headers were reported from the server. This has been a long-standing problem with Chrome that has gone un-addressed. Other browsers are not susceptible to this problem. Still, it's a fairly easy problem to troubleshoot and, indeed, when I searched on this error, the first search result had the solution: remove commas from filenames when handling a request from Google Chrome.
However, this wasn't a direct link, it was an AJAX-request, which results in a different exception. In this case, the error provided by Chrome is the cross-origin request exception and this is what made it so difficult to troubleshoot.
So, the tl;dr of it all is to strip out commas in the names of uploaded files.
Another instance I found where this issue occurred is after executing code similar to:
document.domain = '[the exact same domain that the iframe originally had]'
Removing this line of code got rid of this error for me.
We are trying to figure out how something works on the web (for web scraping/automation) and one of the web pages we are working on issues a popup to do some of the work. One of our most commonly used debug tools is the Chrome network tab in Developer Tools, hit "record" do some work, and then examine what was done and then replicate the work done "offline".
However the Developer Tools (in Chrome, Safari and Firefox - all work the same) do not follow requests across a popup, even if you hit "record".
Is there some configuration value I'm missing, or some way to record all network events? We can't use tcpdump/wireshark for this because it's all done over SSL. One option we've considered is a man-in-the-middle https proxy, but I can't find anything pre-written so we'd have to create one ourselves.
I don't know of any way to follow the requests across pop-ups, as each window has its own Web Inspector, however you can use Fiddler to inspect HTTPS requests. It will MITM, and subsequently throw a certificate error, which should allow you to inspect all requests in the order that they happened.
You can use Charles Web Debugging Proxy, which is an app that lets you see all the traffic and even replace some responses with your own. Of course that may break HTTPS so you have to accept the certificate errors, but that's usually a minor problem. It works on Win, Mac and even Linux.
The object inspector cannot inspect what isn't in the current page. Therefore, you will need to open the inspector inside the popup url with same parameters in order to see what it does.
As a tool, you can use a web sniffer to see exactly which url were called during the process.