Overview
HTTP Publishing provides complete control over which applications are delivered to each user. Criteria could base on the ACLs associated with the package files. If the user has access to package files, then the applications in the package are published to the user.
Publishing Architecture
The client sends a request to the server asking for the list of applications for the user. This request is sent while impersonating the user, so that the server can access the user’s token, if needed.
The server’s response is a single XML file that contains the publishing information associated with each application, including its shortcuts, file type associations and DDE entries.
Generating the Publishing Document
App-V 4.5 introduced the concept of package manifest files, which contains all of this information in the correct format. This makes creating an HTTP publishing server a much easier task.
The following is an example publishing document that contains the information for a single application. While it contains a lot of information, most of it comes directly from the package’s manifest file. This simple implementation makes an assumption about the information that is in the manifest file. It assumes that the URLs for OSDs and icons in the manifest file point to the appropriate locations.

As can be seen in this sample, the document element is called <DESKTOPCONFIG>. It contains two child elements, <POLICY> and <APPLIST>. The <POLICY> element has a <REFRESH> element that allows you to specify the Publishing Refresh frequency, in minutes and a Boolean that determines if Publishing Refresh occurs when the user first logs in.
The <APPLIST> section is nothing but a concatenation of the <APPLIST> sections from each of the package manifests to which the user has access. The sample code that follows describes how to generate this list. The <APPLIST> element is where all of the application-specific publishing information is placed. This information is taken directly from the manifest files that were generated by the Sequencer.
The end result of this processing is an XML document that contains all of the information for each package that the user has permission to use. Point your web browser at the publishing.aspx page and check out the results. Remember to enable Windows Integrated Authentication on the website and ACL the package directories appropriately.
Configuring the Client
Once the publishing.aspx page is working correctly, all you need to do to use it is to configure the client to point at the page.
Configure the client:

In this example, the client will connect to the ‘appvwebserver.app-v.in’ webserver over port 80 and retrieve the contents of the ‘appvpublishing.aspx’ page. It will then process the XML document that is returned by the server.
Note that this example uses the standard HTTP protocol, which will not verify the identity of the webserver and will return the data unencrypted. This is only appropriate for scenarios that are inside the corporate firewall. If this were a public Internet scenario, you would use the HTTPS protocol to guard against man-in-the-middle attacks.