Internet DRAFT - draft-babu-navmime
draft-babu-navmime
Network Working Group Babu Neelam
Internet-Draft Independent
Updates: RFC2616 July 21, 2007
(if approved)
Intended status: Standards Track
Expires: January 10, 2008
HTTP Performance extension for NAV systems
draft-babu-navmime-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Typically an NAV (network-based anti-virus) system stores the
entire HTTP response from the server, scan the response for
malware and then transmits it to the client. This extension
attempts to better response time for Web traffic by letting the
NAV (network-based anti-virus) system save the time required for
the NAV system for transmission of data from the NAV system to
the client. In addition, this extension also helps in reporting
download progress and avoiding client connection timeout.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 2
3. Definition of Multipart/proxy-response . . . . . . . . . . . . 3
4. Capability announcement by HTTP clients. . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 3
6. Normative References . . . . . . . . . . . . . . . . . . . . . 3
Appendix A. Sample HTTP response received by a web client . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4
Intellectual Property and Copyright Statements . . . . . . . . . . 5
1. Introduction
Network-based anti-virus systems (hereby referred to as NAV systems)
operate by
1. Re-assembling packets into files,
2. Scanning the file for any malware and
3. Transmitting the data. If any malware is not found, it sends an
error code to the client. Otherwise, it sends the data as-is to
the client.
This extension attempts to better response time for Web traffic by
letting the NAV system save the time required for the NAV system for
transmission of data from the NAV system to the client (step 3).
This extension allows an NAV system to send the packets to the Web
clients, while allowing them to re-assemble for it's scanning
purpose.The clients are expected to receive and store the packets,
but not process the received information. Once the scanning in the
NAV system is complete, it indicates the client whether to go ahead
and process the data already sent to the client or to ignore it
(because it contains some malware). By letting NAV system to send
the packets even before the scanning is complete, it is expected
that the time required to transmit the data from the NAV system to
the client is saved and hence increasing the response time.
In addition, this extension solves other issues.
- With NAV systems, it is possible that clients timeout while the
server is scanning the data. As this extension allows the proxy
to send the data while scanning is still in progress, this is
not an issue anymore
- With NAV systems, clients fail to report the progress of
download as it doesn't receive the data till scanning is
complete in proxy. As this extension allows the proxy to send
the data while scanning is still in progress, this is not an
issue anymore
2. Mechanism Overview
This extension defines
- A new subtype for multipart MIME type & describes the desirable
support required for this subtype in web clients, servers, NAV
systems.
- A way for web clients to announce their support for this
extension: using Accept request header field.
3. Definition of Multipart/proxy-response
(1) MIME type name: multipart
(2) MIME subtype name: proxy-response
(3) Required parameters: none
(4) Optional parameters: none
NAV systems supporting this extension MAY send a message body
containing multipart/proxy-response. When multipart/proxy-response
is sent, no other MIME types are expected in the HTTP response.
The multipart/proxy-response content type contains either two or
three sub-parts, in the following order:
- The first body part is the HTTP response (including response
line, headers) received by proxy from the server.
- The second body part is labeled as text/plain. This body must
indicate whether server's HTTP response should be processed or
ignored. The body for this sub-part should be:
Proxy result PROCEED
OR
Proxy result IGNORE
- This sub-part is required only if the second body part contains
"Proxy result IGNORE". This body part provides HTTP response
that needs to be displayed to the user.
As the NAV system starts receiving the response from HTTP server, it
should store the data into a file for its scanning as well as start
sending the first sub-part to the client as described above. Once the
NAV system receives the HTTP response completely, it should scan the
stored file and then should send the second sub-part and third
sub-part (if necessary) to the client.
For some reason, if a client doesn't receive second and third (when
applicable) sub-parts, it should never store/process the already
received data.
4. Capability announcement by HTTP clients
Clients capable of processing multipart/proxy-response should send
"multipart/proxy-response" as one of the one of the media type.
Typically clients announce "*/*" as "Accept" value. For this reason,
NAV systems MUST not assume support for "multipart/proxy-response"
when "*/*" or "multipart/*" is announced by clients in "Accept". An
explicit announcement of "multipart/proxy-response" must only be
considered.
5. IANA Considerations
This document (if approved) requests IANA to allocate
"proxy-response" sub type for "multipart" MIME type.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
Some programs like browsers' "Download Manager" start storing the
data to disk even before the complete response is received. Such
applications should ensure that they delete any partial data in the
event of "Proxy response IGNORE" or when second/third body (when
applicable) parts are not received. At times, it is possible that a
workstation auto-restarts/crashes after starting to receive the HTTP
response and before secind and/or third sub-parts. For this reason,
such programs are expected to save data only to some temporary
directory. After the download is complete, they are are expected to
be moved to the path requested by the user. After a system restart,
client should ensure that they clean up this temporary directory.
7. Normative References
[RFC2616] 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.
Appendix A. Sample HTTP response received by a web client
HTTP/1.1 200 OK
Content-Type: multipart/proxy-response
HTTP/1.1 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/html
Content-Length: 1354
<html>
<body>
<h1>Happy New Millennium!</h1>
(more file contents)
.
.
.
</body>
</html>
Content-type:text/plain
Content-length: <blah>
Proxy result IGNORE
Content-type: text/plain
Content-length: <blah>
The requested URL contains malware
Author's Address
Babu Neelam
Intoto Software India Private Ltd.
8-3-1111/2, kesava nagar colony,
sriniagar colony main road,
punjagutta,
Hyderabad,
India.
Email: babun@intoto.com
Comments are solicited and should be addressed to the working
group's mailing list at ietf-http-wg@w3.org and/or the author(s).
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
