Fixes to documentation
This commit is contained in:
parent
fd898205b3
commit
4991ad3e24
|
@ -978,32 +978,6 @@ lists all the configuration directives</p>
|
||||||
list.
|
list.
|
||||||
</td>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
|
||||||
<td valign=top >
|
|
||||||
<tt>ua-profile-cache-directory</tt>
|
|
||||||
|
|
||||||
</td>
|
|
||||||
<td valign=top >
|
|
||||||
Directory name
|
|
||||||
(string)
|
|
||||||
</td>
|
|
||||||
<td valign=top >
|
|
||||||
User Agent
|
|
||||||
Profile Cache: When an MMS client requests (via HTTP GET command) a message
|
|
||||||
about which it has been notified, it sends its profile URL (such as
|
|
||||||
<tt>http://nds.nokia.com/uaprof/N3650r100.xml </tt>
|
|
||||||
for the Nokia 3650) as part
|
|
||||||
of the HTTP request headers. The gateway should fetch the URL presented and
|
|
||||||
parse it to figure out the client's capabilities (so-called <i>User Agent
|
|
||||||
Profile</i>). It would be inefficient to fetch the profile data each time from
|
|
||||||
an external server, therefore the gateway caches fetched profile data in the
|
|
||||||
directory specified here. Cache entries are never expired (which is unlikely
|
|
||||||
to be a problem). Some badly behaved MMS clients to do not submit a profile
|
|
||||||
URL. In this case, the gateway relies on the HTTP
|
|
||||||
<i>Accept</i> request headers to determine its
|
|
||||||
capabilities.
|
|
||||||
</td>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
<tr>
|
||||||
<td valign=top >
|
<td valign=top >
|
||||||
<tt>billing-library</tt>
|
<tt>billing-library</tt>
|
||||||
|
@ -1551,7 +1525,7 @@ request. When such a request is received, the proxy:
|
||||||
|
|
||||||
<li> Locates the message: From the URL, the proxy can tell if this
|
<li> Locates the message: From the URL, the proxy can tell if this
|
||||||
is a message in the MMbox or in the in the queue for client-destined messages.
|
is a message in the MMbox or in the in the queue for client-destined messages.
|
||||||
<li> Extracts the User Agent profile URL from the (HTTP) request
|
<li> Extracts the User Agent Profile URL from the (HTTP) request
|
||||||
headers. If that is missing, the profile information is built out of
|
headers. If that is missing, the profile information is built out of
|
||||||
the HTTP Accept headers. The profile URL is passed to the content
|
the HTTP Accept headers. The profile URL is passed to the content
|
||||||
adaptation module, which performs various modifications to the MM such
|
adaptation module, which performs various modifications to the MM such
|
||||||
|
@ -1563,6 +1537,8 @@ as:
|
||||||
<li> Converting text to a supported character set
|
<li> Converting text to a supported character set
|
||||||
<li> Removing unsupported content from the MM
|
<li> Removing unsupported content from the MM
|
||||||
</ul>
|
</ul>
|
||||||
|
note that profile data is cached
|
||||||
|
(in <tt><i>storage-directory</i>/UserAgent_Profiles</tt>) so as not to have to fetch it each time.
|
||||||
<li> The message is then packed and returned to the client as the
|
<li> The message is then packed and returned to the client as the
|
||||||
result of the HTTP request.
|
result of the HTTP request.
|
||||||
|
|
||||||
|
@ -1809,4 +1785,4 @@ format.
|
||||||
<!-- begining of footer -->
|
<!-- begining of footer -->
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
<!-- end of footer -->
|
<!-- end of footer -->
|
||||||
|
|
Loading…
Reference in New Issue