Http/2 is enabled on server and yesterday I noticed that on Iphone (IOS 10.2) does not load some resources with error:failed to load resource:connecting to server is not possible. When I connect Iphone to Mac there are no errors in console but simply result of some requests result imidiatelly in that error. Interesting thing could be the fact that resources which are not loaded are subdomain of real domain( CNAME to be correct). Site is on https.
Server is Windows server 2016.
EDIT:
We resolved this subdomain problem, but still there are requests from same domain that are not responding with any response.
I know IOS > 9.3 supports http/2 when resources are loaded over https but thing that resources which not working are not part of that domain could help to resolve this problem but I don't know how.
I know that probably problem is related to http/2 protocol because my android native appliacation also stopped working with error : java.io.IOException: stream was reset: PROTOCOL_ERROR . I resolved that problem by forcing my application to use http/1. Now works. But how to resolve that iphone safari problem?
I'm using ASP.NET Web Forms as backend (which supports http2 since ASP.NET 4.6 which I'm using).
It seems that solution has been found. After few days of investigating disabling dynamic content compression helped.
The answer has already been correctly provided here above by Vlado Pandžić.
I cannot comment as I am new on this site, but I wanted to add something I found.
IOS less than version 11 does support HTTP/2. BUT! It will get stuck if the page is too big and compressed. I'm not sure what the cut-off is, but if you open a small page which has dynamic compression (Gzip or whatever) it will work fine. ASP or PHP etc, doesn't matter. Once the page reaches a compressed data size which requires multiple round-trips to pull the data, then Safari gets it's knickers in a twist.
It will literally go into an endless loop, hammering your server with requests. I was seeing thousands of page hits while Safari was just stuck on a blank white screen.
The problem for me, is that disabling dynamic compression on your entire website will result in penalties from Google for mobile-friendliness. Google wants you to have compression on, but you have to disable it for Safari, which sucks.
My solution to this was the enable dynamic compression on the entire website, but I used web.config file to disable it for specific pages which I know can be quite large in size.
<location path="large-page.aspx">
<system.webServer>
<urlCompression doDynamicCompression="false" />
</system.webServer>
</location>
Good luck!
Matt
You can also disable gZip and use brotli instead for compression, older versions of Safari don't support it so it seems to work.
https://github.com/saucecontrol/Brotli-IIS
This is quite an old thread, however, there's a better answer if you need don't want to cut off old iOS devices than disabling all compression for either this site (accepted answer) or for all browsers for a given resource (Matt Deemer).
A URL Rewrite rule can disable compression just for the resources and browsers that matter.
Recently, I wanted to move an established Classic ASP site, which can serve large, dynamically created resources, to HTTP/2.
The following rule allowed everyone but old WebKit versions to get the content compressed.
<rule name="No compression for old WebKit">
<match url="^(.+\.asp.*)" />
<conditions>
<add input="{HTTP_USER_AGENT}" pattern="AppleWebKit\/60[0-3]" />
</conditions>
<serverVariables>
<set name="HTTP_ACCEPT_ENCODING" value="none" />
</serverVariables>
<action type="Rewrite" url="{R:1}" />
</rule>
NOTES: WebKit/604 and greater do not have the http/2 - compression issue.
url-rewriteclassic-asp
Related
Recently the google search console reported a coverage issue on our ASP.NET website for the urls pointing to PDF documents.
So far in our web.config file we don't have any MIME setting for PDF documents. But indeed, both on localhost and in production, in Chrome, in mobile context PDF url generate empty content with the message no enabled plugin supports this MIME type:
In Desktop context the PDF document is opened directly in Chrome.
Updating the web.config file with that (below) leads to the same described behavior, both in mobile and desktop contexts.
<system.webServer>
<staticContent>
<remove fileExtension=".pdf" />
<mimeMap fileExtension=".pdf" mimeType="application/pdf" />
</staticContent>
<system.webServer>
Updating the web.config file with that (below) forces the browser to download the PDF in both contexts.
<system.webServer>
<staticContent>
<remove fileExtension=".pdf" />
<mimeMap fileExtension=".pdf" mimeType="application/octet-stream" />
</staticContent>
<system.webServer>
So far this is the best solution since it allows mobile users to get the PDF and this will fix the google warning.
However I'd like to open the PDF in the browser itself in desktop context and download it in mobile context. Is it possible?
The observed behavior is device/media-type specific; handling this at the web server level is challenging to put it mildly. There are some simple approaches but they take you only so far, some commercial IIS detection solutions can help.
I guess, making adjustments to the website would be probably more beneficial. There might be header issues, or acknowledging this behavior and manage the expectations.
Consistent behavior across mobile devices is difficult and there is simply no foolproof way to determine whether a device, mobile OS, or form factor is able to open in HTML-embedded PDF documents like it is the case on the desktop. The lowest common denominator of displaying an embedded document on all common browsers and devices is usually having a download link.
For me the issue was viewing the page in responsive mode, Chrome doesn't support showing pdf in this mode, switched to regular desktop mode and the PDF appeared. The mobile view can be tested by switching back to responsive mode after the file has been loaded.
I had the same error message for a relative PDF link at localhost, but the same url worked as expected when deployed to a live https url
I have searched many question on SO related to this. But nothing solves my issue.
I am using google recaptcha v2 in an asp.net mvc5 app. It works fine in google chrome. But it is showing some error in firefox and edge browsers. I suspect this as something related to content security policy headers.
Error in Firefox
Content Security Policy: Ignoring “'unsafe-inline'” within script-src: ‘strict-dynamic’ specified
Content Security Policy: Ignoring “https:” within script-src: ‘strict-dynamic’ specified
Content Security Policy: Ignoring “http:” within script-src: ‘strict-dynamic’ specified
Error in Edge
Security of a sandboxed iframe is potentially compromised by allowing script and same origin access.
Due to this error recaptcha is not working since it get timed out everytime
I've tried to add csp headers like this in web.config
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="script-src 'self' 'unsafe-inline' https://www.google.com https://www.google.com/recaptcha/api.js https://www.gstatic.com" />
</customHeaders>
</httpProtocol>
</system.webServer>
But this doesn't work as well as my page got broken since all other files got blocked by the browser
It doesn’t appear that the script’s failure is CSP related. Those aren’t really errors you’re getting; merely notices.
In CSP some policies override other policies, so you get a notice that policy A is ignored because you’re using policy B. So why put policy A in at all, you ask? For compatibility with older browsers that don’t understand policy B.
For example: I use CSP nonces, but also put in “unsafe-inline”. IE doesn’t understand nonces so it uses the “unsafe-inline” rule. Modern browsers ignore the “unsafe-inline” and use the nonces. In Firefox console I get a notice similar to what you’re getting
To be able to use Edgecast CDN, we had to write a custom media provider which worked well with before the site was upgraded from 6.5 rev 111230 to 120427. After the upgrade, none of the images showed up on the website. I debugged the code and found a probable cause. In the upgrade following fix was included -
By default, media URLs will now be generated relative to the site root (such as /~/media/images/picture.ashx or /virtualFolder/~/media/picture.ashx) instead of relative to the current page. Such URLs are considered SEO friendly, and also improve caching. (346213, 332285)
This is now adding a leading slash "/" at the beginning of the media urls. So urls are not getting generated as "//mediaserver/abc.jpg". The 'MediaUrlOptions.VirtualFolder" is being set to "/" by default. I want to confirm that this is the issue and also if I can override this in code but I want to find out if this can be controlled from the config file instead of making this change in the code.If this is not the issue then how can I fix this problem?
In the interest of providing the answer here:
Remove the slash in the Media.MediaLinkPrefix setting due to Sitecore automatically adding it now:
<setting name="Media.MediaLinkPrefix" value="/mediaserver" />
As well as in the following one:
<handler trigger="/mediaserver/" handler="sitecore_media.ashx" />
Also, Media API improvements have been made since version 6.5.0 rev. 120427. Now it is possible to elegantly override the MediaProvider class using a web.config setting per reference number 312358 in release notes on the SDN:
http://sdn.sitecore.net/Products/Sitecore%20V5/Sitecore%20CMS%206/ReleaseNotes/ChangeLog.aspx
I'm trying to implement File API for image uploading following this example
http://robertnyman.com/html5/fileapi-upload/fileapi-upload.html
On the server side I'm using ASP.NET MVC 3 with IIS7 (integrated, 32 bit only)
Everything works fine locally with Development Server and IIS7.5. On the server it also works, except that if a file is of a certain size (working with a 2.2MB image file) the upload seems to be working but the response is a 404 page. I've configured the maxRequestLength to be 10MB, but even with the default 4MB it should have worked.
The 404 page I get back is the IIS7 by default 404, not my application's 404 page (by looking at the result in Fiddler or Firebug). I'm catching all random URLs and displaying a custom 404 page, but in this case it seems like the request is not sent to the ASP.NET pipeline (the Application Pool is set to Integrated).
I'm also logging any exception that may occur (including 404s) -- the log is clear as far as this problem. There's nothing in the server's event log either.
Any ideas?
Thanks!
It had nothing to do with HTML5 File API or ASP.NET MVC.
The problem was that in IIS7 you have to specify the maxAllowedContentLength. The advertised default value is 4MB, but this doesn't seem to be the case since uploading a 2MB file failed. Interestingly, the local IIS7.5 (Windows 7) doesn't seem to have this problem -- maybe it's fixed in IIS7.5 (Windows Server 2008 R2)
To fix it, in your web.config make sure you have something like this:
<system.webServer>
...
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="10485760" />
</requestFiltering>
</security>
...
</system.webServer>
The value is in bytes; I specified 10MB
I'm trying to access my TFS Server using SVNBridge so I can work disconnected. I tried using the server-based as well as client-based solution. I'm just getting internal server 500 errors returned. I'm not sure I'm connecting to the site correctly though.
Other posts I've read concerning SVNBridge seem to exclusively be about CodePlex and connecting to it through a CodePlex specific URL.
I'm trying to connect to my own TFS server and wondering how to properly format the URL. Do I need to do something special for that? I feel like I've tried everything. Anybody have any success doing such a thing?
So apprently the problem is related to TFS 2010 Beta 2. The issue is being tracked here:
http://svnbridge.codeplex.com/Thread/View.aspx?ThreadId=77164
Thanks.
Not sure if you are still looking for an answer but I just spent the better part of my weekend getting it to work, mostly through trial and error so here is what I learned.
You CANNOT download the zip files and get anything to work if you are using TFS-2010. Instead you MUST download the source code and compile the thing for yourself.
You have to do the build on a computer with IIS installed to use the website project as is. This is what I did rather than change the project to use the development web server.
If you don't have VS-2008 installed anymore you can just upgrade the whole solution to VS-2010 and everything will be fine. I even changed the target of the website project to the 4.0 Framework with minimal issues. I had to unload the TestsRequiredTfsClient project and the Tools.HttpSend project to get the rest of the projects to build.
After you have built the project you need to follow a couple of steps that are outlined on the SvnBidge home page in order to get the bits into the right location on the web server. Once that is complete then you need to tune up the web.config file.
Here are the appSettings that you need to change and the values you need to use:
<add key="LogPath" value="--directoryYouWantToKeepLogsIn--" />
<add key="DomainIncludesProjectName" value="False" />
<add key="TfsUrl" value="http://--tfsServerName--:8080/tfs/--projectCollection--" />
<add key="ReadAllUserDomain" value="--yourDomain--" />
<add key="ReadAllUserName" value="--domainUserName--" />
<add key="ReadAllUserPassword" value="--domainUserNamePassword--" />
If you decided to upgrade the website to the 4.0 Framework don't forget that you need to update the application pool to because it was probably created as 2.0.
After you are almost done now that the website is set up. You still need to install some performance counters from the SvnBridge.PerfCounter.Installer project. After complication just copy those bits over to the same server you just installed the website on and run the exe.
THIS DIDN'T WORK
Okay so last but not least is security. I don't use the Digest security because all of my users have a windows login so I left anonymous access enabled and then disabled all other forms of access except Windows Authentication.
Windows Authentication didn't work for all of the users, some of them were remote. After looking at the source code it became clear that Basic Authentication was the only choice that was going to work. I needed the users to log in as them selves and then have that username passed into TFS so that as the check-ins are done they can be recorded to the correct user.
RP