I want to implement deep linking in my app. I've read that to implement deep linking you need to put a json file in the root of your website which will then redirect users to the app if they are on a mobile device and the app is installed. I have a Squarespace site, but placing the json file in the root folder of the squarespace files doesn't seem to work. I assume this is because I would need access to squarespaces' own root.
So my question is, can I implement deep linking with a Squarespace site? If so, what have I done wrong? If not, is there an alternative solution, or should I create a new website that I have full access to?
I checked with Squarespace support... first rep was decent, but didn't have the depth, so he sent it up the chain.
Eventual response: Nope, even in their "developer mode" you cannot get the file in the right place with the right MIME type.
Time to look for a different hosting service, or consider Alex Bauer's comment.
A couple notes:
The file must be on https:// - plain old http:// won't work.
The file cannot have an extension - so no .json on the end.
The file' MIME-type must be set to application/json. This can be a hassle, as standard web service sets MIME-type by extension.
Otherwise - it's fairly straight-forward :)
The requirements around hosting the apple-app-site-association file needed by Universal Links are quite strict. I doubt it is possible to satisfy them with the standard Squarespace system, though it might be possible via Developer Mode.
As a workaround, you could add something like the Branch.io Smart Banner (full disclosure: I'm on the Branch team). This won't make your site URLs active for Universal Links, but it will make it easier for users to transition between your site and the app.
I found a soloution.
You can enable a URL Mapping to point on appname://location/xy
This is not a soloution for universal links but you can handle deeplinks in that way.
Hope this helps.
I don't think this is a Squarespace issue as much as a maybe a design issue. If you register the appropriate intents you can make a 1 page to 1 view association in your app. The example below is Android but you can do similar on iOS
Case:
Web Address: www.abc123.com/news
App Page: News
Example Intent (Android)
<activity
android:name="com.abc123.android.NewsActivity"
android:label="#string/title_news" >
<intent-filter android:label="#string/filter_title_viewnews">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="http"
android:host="www.abc123.com"
android:pathPrefix="/news" />
</intent-filter>
</activity>
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
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
I know that to access an external link, one has to whitelist the access path in config.xml.
My problem is that I am unable to use asterisk as the whitelist option. Ripple emulator does not let me do it. My app downloads a number of image links and then display those images. These images could come from any number of sources/ domains. Now how do I mention an intelligent whitelist for this purpose?
My Environment:
BlackBerry 10 WebWorks SDK 1.0.4.11
BB10 Simulator
Windows 7
The way you do that is adding this line in the config.xml file:
<access subdomains="true" uri="*" />
But there's a quirk that renders this option useless whenever you use ajax. From the docs:
You can specify a wildcard () for the uri to whitelist any domain, but only for domains that do not access application APIs and that do not access content through XMLHttpRequest. If the domain requires access to APIs or accesses data through XMLHttpRequest, you must explicitly specify the domain in the uri.*
As Mister Smith said above, the proper way to 'whitelist' a domain is by adding the wildcard access element to your config.xml
<access subdomains="true" uri="*" />
You also have the ability to disable all web-security. While this is not the first recommended approach to dealing with cross origin requests, it's sometimes needed, especially when talking to services that use a CDN. To disable all web-security you'll want to add the following to your config.xml
<feature id="blackberry.app" >
<param name="websecurity" value="disable" />
</feature>
Lastly, your Ripple issue is something separate from all of this.
Go to manage your Chrome extensions, find Rippe, and check the box that says "Allow access to file URLs", and add the following flag to your Chrome shortcut --allow-access-from-files
Has anyone been successfully rendering charts using fusion charts in a sandboxed solution?
How would you get the SWF file onto SharePoint? I included it and deployed it via feature and the Elements.xml looks like the following:
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Name="FusionCharts">
<File Path="FusionCharts\FCF_Column2D.swf" Url="FusionCharts/FCF_Column2D.swf" />
<File Path="FusionCharts\FCF_Gantt.swf" Url="FusionCharts/FCF_Gantt.swf" />
</Module>
</Elements>
When the sandbox solution is deployed, you can access the SWF file from http://sharepointsite/FusionCharts/FCF_Gantt.swf, the browser will attempt to open/save the file. If this file is deployed via farm solution, and be deployed to _layouts folder, which I can access via http://sharepointsite/_layouts/FusionCharts/FCF_Gantt.swf, it renders with error message "invalid xml data". The farm solution deployment is correct because MIME type is properly set to "application/x-shockwave-flash" and thus my custom web part which renders chart using this SWF file works. But if my sandboxed web part is to use the SWF file deployed as site pages, it does not work. Any idea?
Thanks in advance.
Sean
The problem is resolved with help from DevExpress team. Though SWF can be deployed to SharePoint site document library, you would need Farm Administrator to go into Central Admin pages and set the property in Application Management for the Web application to allow "Permissive". Go to Central Admin -> Application Management -> Select Web Application -> General Settings (Ribbon button), change "Browser File Handling" from "Restrict" to "Permissive".
I have a ASP MVC web application that uses a plugin to load images and points for a 3d application.
When debugging with the the Visual Studio development server the images and the points are served up great...
http://i148.photobucket.com/albums/s19/littleniv/Debugging/local.png
Second image: same url but iis.png
When running in IIS 7 though the .Dat point files do not serve and produce a 404.
I've noticed the caching is marked as private in fiddler, but i don't know what this means. Can anyone help?
Cheers,
Stu
It's been a while, but I have seen a similar issue in IIS 6. IIS by default will only serve a file if it is configured to serve it based on the extension and mime type.
Go into the IIS Manager, click on the server, then open up "MIME Types" under the IIS Area. Hit "Add..." in the upper right corner (under actions), and type in your extension (".dat") and a mime type (depends on your data; maybe "application/octet-stream"?).
Once you've done that, you should be able to download the files.
I ran into this issue while trying to serve a blazor wasm application.
First try to browse the application locally on the web server. If you see an error similar to image below,
Network Tab Screenshot
You can make out that the Requested URL shows, Rejected-By-UrlScan added to the actual URL.
So the url scan is rejecting the .dat file request. To fix this url scan has to be configure to serve dat file types.
Open up UrlScan.ini (I found it in C:\Windows\System32\inetsrv\urlscan folder)
Find the DenyExtensions section and comment / remove the line starting with .dat
Now you will be able to load .dat files.
Hope, this answers helps someone.
OK. Apparently the 404.3 50 error is ERROR_NOT_SUPPORTED. Can anyone shed any light?
ALL STOP!!!
I added a static file handler mapping and everything is solved. Many thanks to Chris for helping me run through some trouble shooting. I'll mark you as the answer as you are the only one that helped!! Thanks again!!
Eek. I have multiple accounts on SO... this is going to take some sorting out!
For an Azure web app, the following change to the web.config did the trick, thanks for the Mime type clue:
<system.webServer>
<staticContent>
<remove fileExtension=".dat" />
<mimeMap fileExtension=".dat" mimeType="application/octet-stream" />
</staticContent>
</system.webServer>