Http content type apple

HTTP Live Streaming Overview

Deploying HTTP Live Streaming

To actually deploy HTTP Live Streaming, you need to create either an HTML page for browsers or a client app to act as a receiver. You also need the use of a web server and a way to either encode live streams as MPEG-2 transport streams or to create MP3 or MPEG-4 media files with H.264 and AAC encoding from your source material.

You can use the Apple-provided tools to segment the streams or media files, and to produce the index files and variant playlists (see Download the Tools ).

You should use the Apple-provided media stream validator prior to serving your streams, to ensure that they are fully compliant with HTTP Live Streaming.

You may want to encrypt your streams, in which case you probably also want to serve the encryption key files securely over HTTPS, so that only your intended clients can decrypt them.

Creating an HTML Page

The easiest way to distribute HTTP Live Streaming media is to create a webpage that includes the HTML5 tag, using an .M3U8 playlist file as the video source. An example is shown in Listing 3-1 .

Listing 3-1 Serving HTTP Live Streaming in a webpage

For browsers that don’t support the HTML5 video element, or browsers that don’t support HTTP Live Streaming, you can include fallback code between the and tags. For example, you could fall back to a progressive download movie or an RTSP stream using the QuickTime plug-in. See Safari HTML5 Audio and Video Guide for examples.

Configuring a Web Server

HTTP Live Streaming can be served from an ordinary web server; no special configuration is necessary, apart from associating the MIME types of the files being served with their file extensions.

Configure the following MIME types for HTTP Live Streaming:

File Extension

MIME Type

If your web server is constrained with respect to MIME types, you can serve files ending in .m3u with MIME type audio/mpegURL for compatibility.

Index files can be long and may be frequently redownloaded, but they are text files and can be compressed very efficiently. You can reduce server overhead by enabling on-the-fly .gzip compression of .M3U8 index files; the HTTP Live Streaming client automatically unzips compressed index files.

Shortening time-to-live (TTL) values for .M3U8 files may also be needed to achieve proper caching behavior for downstream web caches, as these files are frequently overwritten during live broadcasts, and the latest version should be downloaded for each request. Check with your content delivery service provider for specific recommendations. For VOD, the index file is static and downloaded only once, so caching is not a factor.

Validating Your Streams

The mediastreamvalidator tool is a command-line utility for validating HTTP Live Streaming streams and servers (see Download the Tools for details on obtaining the tool).

The media stream validator simulates an HTTP Live Streaming session and verifies that the index file and media segments conform to the HTTP Live Streaming specification. It performs several checks to ensure reliable streaming. If any errors or problems are found, a detailed diagnostic report is displayed.

You should always run the validator prior to serving a new stream or alternate stream set.

The media stream validator shows a listing of the streams you provide, followed by the timing results for each of those streams. (It may take a few minutes to calculate the actual timing.) An example of validator output follows.

Serving Key Files Securely Over HTTPS

You can protect your media by encrypting it. The file segmenter and stream segmenter both have encryption options, and you can tell them to change the encryption key periodically. Who you share the keys with is up to you.

Key files require an initialization vector (IV) to decode encrypted media. The IVs can be changed periodically, just as the keys can. Current recommendations for encrypting media while minimizing overhead is to change the key every 3-4 hours and change the IV after every 50 Mb of data.

Even with restricted access to keys, however, it is possible for an eavesdropper to obtain copies of the key files if they are sent over HTTP. One solution to this problem is to send the keys securely over HTTPS.

Before you attempt to serve key files over HTTPS, you should do a test serving the keys from an internal web server over HTTP. This allows you to debug your setup before adding HTTPS to the mix. Once you have a known working system, you are ready to make the switch to HTTPS.

There are three conditions you must meet in order to use HTTPS to serve keys for HTTP Live Streaming:

You need to install an SSL certificate signed by a trusted authority on your HTTPS server.

The authentication domain for the key files must be the same as the authentication domain for the first playlist file. The simplest way to accomplish this is to serve the variant playlist file from the HTTPS server—the variant playlist file is downloaded only once, so this shouldn’t cause an excessive burden. Other playlist files can be served using HTTP.

You must either initiate your own dialog for the user to authenticate, or you must store the credentials on the client device—HTTP Live Streaming does not provide user dialogs for authentication. If you are writing your own client app, you can store credentials, whether cookie-based or HTTP digest based, and supply the credentials in the didReceiveAuthenticationChallenge callback (see Using NSURLConnection and Authentication Challenges and TLS Chain Validation for details). The credentials you supply are cached and reused by the media player.

Important: You must obtain an SSL certificate signed by a trusted authority in order to use an HTTPS server with HTTP Live Streaming.

If your HTTPS server does not have an SSL certificate signed by a trusted authority, you can still test your setup by creating a self-signed SSL Certificate Authority and a leaf certificate for your server. Attach the certificate for the certificate authority to an email, send it to a device you want to use as a Live Streaming client, and tap on the attachment in Mail to make the device trust the server.

Copyright © 2016 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2016-03-01

Источник

Http content type apple

Developer

App Search Programming Guide

Mark Up Web Content

If some or all of your app’s content is also available on your website, you can use web markup to give users access to your content in search results. Using web markup lets the Applebot web crawler index your content in Apple’s server-side index, which makes it available to all iOS users in Spotlight and Safari search results.

In addition to adding web markup, it’s strongly recommended that you support universal links. Adding support for universal links further enhances the user experience by opening your native app when users tap a link to your website (if your app isn’t installed, tapping the result opens Safari). This behavior helps websites that contain large amounts of data to be indexed and searchable by all users.

To learn how to use universal links, see Support Universal Links . Figure 5-1 shows an example of using universal links to let users tap a website link and open an app.

Figure 5-1Using universal links to support opening a website link in an app

To make your content searchable using web markup, follow these three steps:

Make sure that Apple can discover and index your website.

Add markup for deep links from your website into your app.

Enrich your search results by adding markup for structured data.

Because items indexed by Applebot are already public, they are stored on Apple’s server-side index.

Making Your Website Discoverable by Apple

The easiest way to make sure that the Applebot web crawler crawls your website is to specify the URL as your support or marketing website when you submit your app. To learn more about specifying this URL, see Version Information .

Figure 5-2Specifying the support and marketing URLs

In addition, it’s critical that you amend your robots.txt file to allow Applebot to crawl your website. Applebot checks your robots.txt file to determine which parts of your website it should crawl. (You can learn more about the robots.txt file on Wikipedia.) To detect Applebot, you can use a regular expression.

Applebot ignores the fragment identifier component of a URL.

Use the App Search API validation tool to verify the data that Applebot is able to extract from your website. The information from the validation tool can help you identify pieces of information that you should add and can help you discover ways to optimize your website metadata. You can access the validation tool here: https://search.developer.apple.com/appsearch-validation-tool.

Adding Deep Links to Your Website

The best way to help the users of your website discover your app is to adopt Smart App Banners (you can learn more about Smart App Banners by reading Promoting Apps with Smart App Banners). A Smart App Banner on your website invites users who don’t have your app installed to download it from the App Store, and it gives users who already have your app installed an easy way to open a page deep within it. Figure 5-3 shows an example of a Smart App Banner.

Figure 5-3A Smart App Banner redirecting users into your installed app

Including an app-argument value in your Smart App Banner markup allows Apple to index your content. To include an app-argument value, you can use markup similar to this:

It’s critical that the app-argument value contain the URL into your native app that corresponds to the specific web content that the user is currently viewing. Don’t leave the app-argument value set to the URL of your app’s opening screen.

In addition to adding a Smart App Banner, it’s strongly recommended that you use universal links with your deep links instead of using a custom URL scheme. When you support universal links, iOS can use Handoff to launch your app and provide you with the specific web URL that the user was viewing. To learn how to support universal links, see Support Universal Links .

As an alternative to using Smart App Banners, you can use one of the open standards that Apple supports to provide deep links on your website, such as Twitter Cards and App Links. For example, you might use Twitter Cards markup similar to the following:

Or you could use App Links markup in a similar way:

For more information about Twitter Cards, see https://dev.twitter.com/cards/mobile; for more information about App Links, see http://applinks.org.

After you mark up your website with deep links, you want to make sure that your app can handle them. When you support universal links, iOS calls your application:continueUserActivity:restorationHandler: delegate method when a user taps a deep link into your app. If you use a custom schema, iOS calls openURL: to open your app. Listing 5-1 shows an example of using openURL: to handle a deep link from a Smart App Banner.

Listing 5-1Handling deep links

1. // In this example, the URL is » http://example.com/profile/?123 «.
2. func application ( application : UIApplication , openURL url : NSURL , sourceApplication : String ?, annotation : AnyObject ) -> Bool <
3. if let components = NSURLComponents ( URL : url , resolvingAgainstBaseURL : true ), let path = components . path , let query = components . query <
4. if path == «/profile» <
5. // Pass the profile ID from the URL to the view controller.
6. return profileViewController . loadProfile ( query )
7. >
8. >
9. return false
10. >

To learn more about handling universal links in your app, see Preparing Your App to Handle Universal Links .

Enriching Search Results

Marking up structured data on your website helps Apple better parse and understand your content and provide richer search results. For example, in addition to providing a title and a description for an item, you can include metadata such as an image, prices, ratings, and other details. The biggest advantage of providing structured data is that it can help you improve the ranking of your search results: Users tend to engage more with results that include richer information; moreover, results that get more engagement are shown more frequently.

To annotate your web content so that users can see rich search results, use standards-based markup for structured data, such as that defined at Schema.org. For example, the code shown in Listing 5-2 combines different types of markup to give users the rich information shown in Figure 5-4 .

Listing 5-2Using markup to provide rich information

1. Beats by Dr. Dre Solo2 Wireless Headphones — Apple
2. 924

Although you must supply the deep link, title, and description elements to index an item, it’s strongly recommended that you also include a content-specific image.

The following schemas are currently supported:

Источник

anhar / setting_up_ios_universal_links.md

Setting up iOS Universal Links

Table of Contents

Here are some good URLs that might be of assistance:

General link resources

Follow these steps to setup Universal app linking on the web server. In this documentation we have examples for Apache2 and nginx but the same rules apply for IIS or any other webserver of your choice.

Apple JSON Metadata file

Create a JSON file called «apple-app-association«

For iOS12 and earlier

Below you’ll find a template with a few examples:

PLEASE NOTE!

• The «apps»: JSON key must be left as an empty array.
• The apple-app-site-association JSON file must not have a .json file extension.

For iOS13 and later

This template gives you a lot more flexibility of how to handle certain URLs on your website. For instance you can specify a required URL query item with a particular name and a value of x numbers of characters. You can exlude URLs with # that is common in AngularJS apps.

PLEASE NOTE!

• The apple-app-site-association JSON file must not have a .json file extension.

Sign the apple-app-site-association file using openssl

OBS: Please note that as of iOS9 you no longer need to sign the apple-app-site-association JSON file. However if you still need to support iOS8 or lower this is still required.

Upload the signed «apple-app-association» file

1. Upload the signed apple-app-site-association file to the server:

1. Login to the web server:

1. Move the file to the root of the webserver (This might be another directory on your server)

Modifying the Content-type of the apple-app-site-association file

The apple-app-association-file needs to be returned with the following Content-Type:

Minimum OS version	Content-Type
iOS9 or later	application/json
iOS8 or lower	application/pkcs7-mime

Below you’ll find instructions on how to do this for your web server.

• Modify the /etc/apache2/sites-available/default-ssl (or equivalent) file to include the snippet:

• Modify the /etc/nginx/sites-available/ssl.example.com (or equivalent) file to include the location /apple-app-assocation snippet:

The JSON validation may fail if:

• The JSON file is invalid
• Redirects to something other than HTTPS
  • From our experience any redirects will make Apples webscraper bot unable to parse the JSON file, you really should avoid them
• The server returns a 400-499 HTTP status code
• The server returns a 500-599 HTTP status code
  • The Apples webscraper bot assumes that the file is temporarily unavailable and may retry again

For more information go to Apples documentation page Supporting Associated Domains in Your App and scroll down to the section «Validate the Apple App Site Association File».

1. In Xcode go to .xcodeproj/ /Capabilities and turn on Associated domains.

2. Enter the domains you want the iOS app to respond to.

Implement the corresponding AppDelegate methods

iOS 9.0 and earlier

• If you already have a custom URI scheme i.e myAppScheme:// , this method will already be implemented.
• We have noticed that devices running iOS 9.0.x responds to this older method of handling app links.
• If you want to support iOS 9.0.x or earlier like iOS8/iOS7 you will need to implement this method and add a JavaScript iframe redirect to your website.

iOS 9.1 and later

• Devices running iOS 9.1 or later supports Apple’s Universal Links and to handle the incoming URL you need to implement the following methods:

Remember that when you make changes to either:

To delete the App from your testing device and compile it again. After an app has been successfully associated with a particular domain it will remain associated until the app is removed from the device.

When testing your deep links I recommend you to use either the iMessage app or the Notes app. If you use other 3rd party iOS applications such as Slack or Facebook Messenger the deeplinking might not work because that’s dependent on how those 3rd party apps handle external URLs.

timbaas commented Aug 18, 2016

Great info, thanks for sharing! I’m not sure if this has changed after time of writing this but currently the file should be named apple-app-site-association instead of apple-app-association 🙂

anhar commented Jan 26, 2017

@timbaas You are totally right, it was a typo on my part 👍

rupeshpatil761 commented Apr 13, 2017 •

Hello @anhar , I went through above document and did changes as mentioned. Even though I am able to validate my site. Please help me. I am using ngnix server. Thanks in Advance

eXhausted commented Apr 19, 2017

too good to be true

jmarus commented Apr 24, 2017

Does the file have to be signed, even if it’s being forced over https?

vj-repo commented May 20, 2017

Hi, Have you tried opening universal links with in the associated domains? I mean if you have only part of website is available for Mobile then you need to remove this «paths»: [ «*» ].

So, when you are in the home page of «example.com» on safari app and if you navigate to «https://example.com/articles/some», it should open app. But for some reasons, it is navigating with in the safari.

It works from outside of associated domains but not from with in the associated domains. Is this how it should be or something wrong with my code?

Thanks in advance,
VJ

dqlobo commented Jun 6, 2017

@vj-repo: I think it’s because of this clause in the documentation:

«When a user is browsing your website in Safari and they tap a universal link to a URL in the same domain as the current webpage, iOS respects the user’s most likely intent and opens the link in Safari. If the user taps a universal link to a URL in a different domain, iOS opens the link in your app.»

anhar commented Jul 18, 2017

@jmarcus Yes the the apple-app-site-association must be signed with the webservers certificates.

@vj-repo Yes, that was an intentional way of showing how to use the wildcard character for all paths.
If you only want to support certain paths of your website you should remove the wildcard part from the example JSON.

eusonlito commented Aug 9, 2017

The apple-app-site-association file must meet the following requirements:

• The file must be hosted on an https:// site with a valid certificate (for example, Safari must not issue a certificate warning when viewing the site).
• The file must not use any redirects.
• In iOS 9.3.1 and later, the file must be no larger than 128 KB (uncompressed), regardless of whether it is signed.
• If your app runs in iOS 9 and later and you use HTTPS to serve the file, you can create a plain text file that uses the application/json MIME type and you don’t need to sign it.
• If your app runs in iOS 8, the file must have the MIME type application/pkcs7-mime and it must be CMS signed by a valid TLS certificate.

cuongnv-ibl commented Jun 14, 2018

How can we show popup Open App when user copy and then paste it that universal link on Safari iOS address bar?

RareSloth commented Aug 1, 2018

prcongithub commented Oct 15, 2018 •

I face this issue even after following the exact same steps.

I am using nginx

I receive no requests on my server when I validate this using the validator tool

aaronbalthaser commented Dec 24, 2018 •

I face this issue even after following the exact same steps.

I am using nginx

I receive no requests on my server when I validate this using the validator tool

Did you ever find a solution? I’m getting the same response from the test tool. I am using Godaddy hosting.

newsplash24 commented Oct 31, 2019

Thank you very much, i was struggling and this article helped me a lot, especially the server configuration part. Thank you again, god bless you 🙂

angelorobo commented Nov 19, 2019

Yes this is what I saw too.

anhar commented Feb 3, 2020

@newsplash24: Thank you for the kind words 😊

As for the application/pkcs7-mime vs application/json debacle I’ve updated the docs to make it a little clearer what you need depending on your minimums OS. Hope that clears it up.

jowinst commented Apr 29, 2020

Hi @anhar! I’d like to ask you if you have an example of an AASA file compatible both for iOS 12 and iOS 13. I am not completely sure which format should the JSON have to support both OS.

anhar commented May 5, 2020 •

Hi @jowinst! If you wanna support both iOS 12 and iOS 13 use the older format. Once you have deprecated iOS 12 in the future you can migrate to using the newer more customizable format.

If you need to use both I guess you could take a look at the User-Agent header and then return different json files depending on the OS version but honestly I think that’s just unnecessarily complicated.

Mukul13cs002 commented May 9, 2020

applinks:*collpoll.com is defined.

A wildcard by prefixing * is not working in my case.
Please help me

acoutts commented May 16, 2020

I’ve been trying to get this to work on a local web server. I have a valid self signed CA/cert installed on the simulator and my computer, and the server is using it too. The cert complies to the ios13 requirements. It shows up as trusted in safari on my macbook and on the simulator.

The domain I’m using is setup with a local network dns server so it points to my dev server. I put this in my entitlements file like this:

My app identifier and provisioning profile are both configured with the capability for universal links enabled.

I created an apple-app-site-association file like this:

When I visit my local server, I get the json response. Its content type is application/json and it’s a 200 status code. I put the same file so it’s at the root and also inside the .well-known folder.

When I install/run my app on the simulator, the web server never receives the request. I’ve only been able to find these messages in the console logs:

It’s clear the request never hits the web server because I don’t see it in the log like when I go to the url directly in my browser. Anyone have any idea how I can make this work in a local dev server for testing?

Hanzofm commented Jun 17, 2020

Hi to all, thanks for your guide.

I am trying to validate my file but I am obtaining:

Link to Application |
Action required
Could not extract required information for application links. Learn how to implement the recommended Universal Links.
| Error cannot fetch app site association

This is my file:

What would be doing wrong?

tevla commented Aug 27, 2020 •

In Apache2, for me adding the Files directive outside of the Directory work, any idea why?

showchi commented Nov 30, 2020 •

In fact, the appIDs are not always Team id. Some apps that were created earlier are a random code called Application id prefix;
You can go to the Apple developer website to verify.

alvynfash commented Dec 12, 2020 •

I’ve been trying to get this to work on a local web server. I have a valid self signed CA/cert installed on the simulator and my computer, and the server is using it too. The cert complies to the ios13 requirements. It shows up as trusted in safari on my macbook and on the simulator.

The domain I’m using is setup with a local network dns server so it points to my dev server. I put this in my entitlements file like this:

My app identifier and provisioning profile are both configured with the capability for universal links enabled.

I created an apple-app-site-association file like this:

When I visit my local server, I get the json response. Its content type is application/json and it’s a 200 status code. I put the same file so it’s at the root and also inside the .well-known folder.

When I install/run my app on the simulator, the web server never receives the request. I’ve only been able to find these messages in the console logs:

It’s clear the request never hits the web server because I don’t see it in the log like when I go to the url directly in my browser. Anyone have any idea how I can make this work in a local dev server for testing?

@acoutts Depending on which OS you’re testing on, i resolved this by following the changes by apple here (take a look at developer mode)

Also, there’s an option for this that can be found in Settings>Developer>Associated Domains.
Try toggling it to on

Источник