I'm trying to implement CesSharp for browser support inside of a Winform/WPF application and running into an issue getting the styles to apply on the page. I'm able to embed the browser into the page, but the styles are completely missing. When I check the log file, I see that they were blocked due to a strict MIME checking, but am unsure where I should go to intercept that check.
"Refused to apply style from 'https://example.com/styles/ig_panel.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.", source: https://example.com/myPage.aspx (0)
If I browse to myPage in the example, above I see that the type is showing as css not html, so I'm not sure where the incorrect MIME type is coming from. Is this something that can be addressed from the CefSharp RequestHandler or does it require changes on the server?
UPDATE: It appears that the css request in question when accessed through CefSharp is getting a http 405 causing the mime type to come out as text/html instead of text/css. Now to determine what's causing the 405.
Related
In my reactapp created by create-react-app I suddenly have an error in chrome when I try to run my app:
Failed to find a valid digest in the 'integrity' attribute for resource 'http://localhost:3000/static/js/0.chunk.js' with computed
SHA-256 integrity 'hW0einVybma+FCDLYbayWASTmGI9JBE1dkrmPvDzJXQ='. The
resource has been blocked.
However in IE it works fine. All I did was changing a label on a Button component. How can I avoid this error on chrome?
It sounds like the feature is simply doing what it's intended to do.
Do you have compression enabled in your Chrome for Android browser?
Google may be minifiying your CSS before sending it to your phone causing the signature to be invalid.
SSL prevents this from happening. Maybe we should look for https in PUBLIC_URL and toggle this feature based on that.
https://developer.chrome.com/multidevice/data-compression
when i load my site from incognito (when static files are not caches), about 50% of the time some static files which are hosted on app engine are not showing up. one time it can be a CSS file and other times it's JS. in the console i see this error:
Failed to load resource: net::ERR_CONNECTION_RESET
I have no idea why this happens and how to fix it.
Also, when you first go the page, you sometimes see a message saying the page is unavailable, and then immediately the page appears.
How to reproduce:
open this page on incognito (each time): http://alephz.com/
about 5 out of 10 times it should come up without CSS or JS
It might be the DNS prefetching having a problem. Try disabling it by adding <meta http-equiv="x-dns-prefetch-control" content="off"> into your header. Have not seen that being a problem for a while though.
The root problem is a certificate mismatch / expired certificate.
You can see this for yourself in the code here.
Note in particular the use of the very constant you reference in the code on line 44 of the C++ file in above link:
case net::ERR_INSECURE_RESPONSE:
The current version of this file is here. The error status ERR_INSECURE_RESPONSE may not any longer be on line 44 but the error code still exists in the SSL certificate portion of the code.
But as you are requesting the resources over SSL it is likely the certificate is invalid. Either it is self-signed and has not been added to your browser/OS exceptions or it is otherwise invalid.
Try the URI directly in the same browser and inspect the certificate.
This is in no way related to jQuery, JavaScript or CSS directly.
I need to add support for a proprietary 3D format in cq5/AEM. Despite having absolutely no experience with this, I managed to generate a few working components to visualize the assets.
But now, I need to create custom media handler to generate renditions and thumbnails from the model. The problem is, media handlers can only work on assets of specific MIME types, and cq5 do not associate a type to my assets. Thus, I can not have a media handler called on them.
Is there any way to customize how cq5 associate MIME types to an asset, or I is there another way to circumvent the problem?
Ok, I found what I needed. You can link MIME type to extensions by going to the OSGI console at http://localhost:4502/system/console/configMgr and to the Apache Sling MIME type Service configuration. There, you can add new MIME / extension link:
MIME extensions...
model/collada+xml dae
I'm using XPages FileUpload control to save some attachments (.xml files) to the document.
By default Domino is saving .xml with "text/xml" MIME type. However I need it to be "application/xml".
Setting FileUpload control "MIME type" option does not help as Domino recognizes file type and changes it.
Is there a way to accomplish this task and manually switch attachment MIME type to a custom one?
You might want to look at "the other end". Instead of trying to alter the mime-type when saving (Which I actually doubt Domino does save!!!), change the way the file is served when retrieved. Instead of using the build in URL to access it, use an XAgent. There you can set the MIME-Type header to your hearts desire.
Edit:
The sneaky way: Don't do anything in your application. Talk to your admin. In the website configuration you can specify rules. Provide the pattern for the XML file and overwrite the mime-type header in the configuration. The admin documentation has all the details. You want to use the "custom header"
I have an Apache server with MultiViews, here's my directory layout:
/style.css [text/css]
/style.xsl [text/xsl]
/index.xml [application/xml]
In my index.xml file, I reference the XSL:
<?xml-stylesheet href="/style"?>
In the XSL, I reference the CSS:
<link rel="stylesheet" href="/style" />
This approach doesn't work in any browser that I have tried.
In Firefox-16.0.1 I see the following message:
Error loading stylesheet: An XSLT stylesheet does not have an XML mimetype:
I debug the HTTP conversation, I notice that Firefox is sending:
Accept: */*
Firefox is requesting any type of content, so Apache chooses to send /style.css.
I would expect web browsers who require specific content types to send explicit Accept headers for those content-types.
I was prepared to submit a bug, when I found two others which explicitly documented getting rid of the Accept constraints.
reduce verbosity of Accept header for fetching XSLT
stylesheet link header doesn't support official XSLT media type
I can work around this by putting the extensions in the file names, but this should work the same way as content negotiation for images, as discussed in the W3C blog. The benefit is that they can add a new content type later without having to update any of their documents.
Is this a bug, or am I getting something wrong?