RFC2936

From RFC-Wiki

Network Working Group D. Eastlake Request for Comments: 2936 Motorola Category: Informational C. Smith

                                                 Royal Bank of Canada
                                                            D. Soroka
                                                                  IBM
                                                       September 2000
                HTTP MIME Type Handler Detection

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

Entities composing web pages to provide services over the Hypertext Transfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. For example, whether an Internet Open Trading Protocol (IOTP) or VRML or SET or some streaming media handler is available. In some cases they would want to display different web pages or content depending on a MIME handler's availability. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on the Internet as of early 2000. It is intended to be of practical use to implementors during the period before the wide deployment of superior standards based techniques which may be developed.

Acknowledegements

Helpful comments by Tony Lewis of Visa have been incorporated.

Introduction

Entities composing web pages to provide services over [HTTP] frequently have the problem of not knowing what [MIME] types have handlers installed at a user's browser. For example, whether an [IOTP] or VRML or [SET] or some streaming media handler is available. In many cases they would want to display different web pages or content depending on a MIME handler's availability. Sending a response with a MIME type that is not supported frequently results in interrupting the flow of the user experience, browser queries as to what to do with the data being provided, and, of course, failure to provide the behavior that would have occurred had the correct MIME type handler been installed.

This document describes reasonable techniques to solve this problem for most of the browsers actually deployed on the Internet as of early 2000. It is intended to be of practical use to implementors during the period before the wide deployment of superior standards based techniques which may be developed. It is written in terms of determining whether a handler for application/iotp or application/x- iotp exists but is equally applicable to other MIME types.

The HTTP 'Accept' Header

The problem should be solved by the Hyper Text Transport Protocol [HTTP] request "Accept" header which lists accepted [MIME] types. This header is present in both Version 1.0 and 1.1 of HTTP and its content is supposed to be a list of MIME types and subtypes that are accepted. The only problem is that many browsers just send "*/*" or the like.

If the particular MIME type you are looking for is specifically present in the Accept header, it is generally safe to assume that a handler for it is actually installed or part of the browser.

NOTE: Although not part of the main topic of this document, if you are designing MIME type handler software and have access to a browser interface that allows you to request the insertion of the MIME type or types your software handles into the Accept header, you generally should do so. It will make it easier for servers sensitive to that MIME type to respond correctly.

JavaScript

Most recent browsers support one or more scripting languages of which the most widely deployed is "JavaScript". These scripting languages appear in web pages and permit the interpretive execution of programming language constructs that can probe the browser environment, conditionally cause different page contents to be displayed, etc. For example, Appendix A shows JavaScript available from the Netscape web site for determining what operating system, browser, and version on which a web page is appearing.

NOTE: JavaScript is a trademark of SUN Microsystems, Inc. It was originally called LiveScript. It has nothing to do with the Java language.

The syntax for script use appears to be a Hyper Text Markup Language (HTML) comment so that browsers that do not support scripting will ignore such items. That is, script use is preceded by "". The following is a simple example of conditional execution of parts of a web page based on JavaScript MIME type handler detection.

<SCRIPT LANGUAGE=JAVASCRIPT> </SCRIPT>

ActiveX and the Windows Registry

If running on Microsoft Windows Internet Explorer version 3 or 4, it is necessary to query the Windows Registry to determine local MIME type support. Although these broswers support JavaScript, in v3 the mimeTypes array is not present and in v4 the mimeTypes array is present but always empty. For example, executing the following code will test for support of the IOTP types:

CString iotpString, xiotpString; char* Key, Keyx;

  int rc, rcx;
  iotpString =

"SOFTWARE\Classes\MIME\Database\Content Type\application/iotp";

  xiotpString =

"SOFTWARE\Classes\MIME\Database\Content Type\application/x-iotp";

  Key = iotpString.GetBuffer(1);
  Keyx = xiotpString.GetBuffer(1);
  rc = RegOpenKeyEx(HKEY_LOCAL_MACHINE, Key, 0, KEY_READ, hDefKey);
  rcx = RegOpenKeyEx(HKEY_LOCAL_MACHINE, Keyx, 0, KEY_READ, hDefKey);

if ( ( rc == ERROR_SUCCESS ) || ( rcx == ERROR_SUCCESS ) )

{
// IOTP Handler exists
}

else

{
// No IOTP Handler
}

NOTE: ActiveX is a trademark of Microsoft and was originally called Sweeper.

ECML, The Electronic Commerce Modeling Language

A industry group has recently proposed a standard for fields used in electronic commerce. This fields allow "wallet" software acting for the consumer to convey standardized information to a merchant, including information as to what payment related protocols are supported at the customer site. See [ECML].

Putting It All Together

The following diagram indicates how these techniques can be put together.

start>-----+

          |
  +------------------+
  | Was desired type |     NO      +-------------------------+
  |found in Accept?  |------------>| Is JavaScript available |
  +------------------+             |and does it show type?   |
        |                          +-------------------------+
   YES  |                            |         |           |
        |<---------------------------+         |        NO |
        |        YES                           |           |
        |                      +---<explorer<--+           |
        |                      |                           |
        |          +----------------------+                |
        |          | Is ActiveX available |                |
        |          |and does it show type?|                |
        |          +----------------------+                |
        |  YES       |        |         |             NO   |
        |<-----------+        |         +----------------->|
        |                     V                            |

remember | Indeterminate. remember |

 that   |.              Take default             that type |

type IS | action. is NOT | supported| supported |

        X done                                             X

Future Development

Active work is proceeding in the IETF, World Wide Web Consortium [W3C], and other standards and industry groups concerning content and capabilities negotiation. This work is likely to lead to superior methods to implement the functionality described herein. However, near universal deployment of such new standards/features will take some time. Thus you should expect the methods given herein to be obsoleted, but perhaps not for some time.

Security Considerations

It should be noted that the variety of ActiveX control suggested above is reading the user's registry, that is, examining their computer and reporting back some information it has discovered. This may be a concern among some users.

In general, the use of JavaScript and, even more so, ActiveX is dangerous because they are so powerful. JavaScript or ActiveX from a web page could be invisibly damaging to the client.

Security of web interactions is normally provided by adopting channel encryption on the browser to server connections, such as [TLS]. In the absence of some such additional security outside of HTTP, requests and/or responses may be forged or tampered with.

IANA Considerations

None specific to the techniques described herein. For MIME types and type registration procedures, see [MIME: RFCs 2046, 2048].

References

[ECML] Eastlake, D. and T. Goldstein, "ECML v1: Field Names for E-

      Commerce", RFC 2706, October 1999.

[HTTP] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext

      Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,

      L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol
      -- HTTP/1.1", RFC 2616, June 1999.

[IOTP] Burdett, D., "Internet Open Trading Protocol - IOTP Version

      1.0", RFC 2801, April 2000.

[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

      Extensions (MIME) Part One: Format of Internet Message
      Bodies", RFC 2045, November 1996.

[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

      Extensions (MIME) Part Two: Media Types", RFC 2046, November
      1996.

[MIME] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part

      Three: Message Header Extensions for Non-ASCII Text", RFC
      2047, November 1996.

[MIME] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet

      Mail Extensions (MIME) Part Four: Registration Procedures",
      RFC 2048, November 1996.

[SET] "Secure Electronic Transaction (SET) Specification, Version

      1.0", May 31, 1997, available from <http://www.setco.org>.
         Book 1: Business Description
         Book 2: Programmer's Guide
         Book 3: Formal Protocol Definition

[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC

      2246, January 1999.

[W3C] World Wide Web Consortium, <www.w3.org>

Appendix A: Browser Version Sniffer Code

 <SCRIPT LANGUAGE="JavaScript">