Network Working Group M. Thomson Internet-Draft Intended Status: Informational M
Total Page:16
File Type:pdf, Size:1020Kb

Load more
Recommended publications
-
Chapter 4: the Hypertext Transfer Protocol (HTTP)
4. The Hypertext Transfer Protocol 4-1 Chapter 4: The Hypertext Transfer Protocol (HTTP) References: • Erik Wilde: World Wide Web — Technische Grundlagen. Springer, 1999, ISBN 3-540- 64700-7, 641 Seiten. • T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext Transfer Protocol — HTTP/1.0. RFC 1945, May 1996, 60 pages. • R. Fielding et al.: Hypertext Transfer Protocol — HTTP/1.1. RFC 2616, June 1999, 176 pages. • J. Franks et al.: HTTP Authentication: Basic and Digest Access Authentication. RFC 2617, June 1999, 34 pages. • David H. Crocker (Ed.): Standard for the Format of ARPA Internet Text Messages. RFC 822, August 1982, 47 pages. • P. Wainwright: Professional Apache. Wrox Press, 1999, ISBN 1-861003-02-1, 617 pages. • D. Kristol, L. Montulli: HTTP State Management Mechanism. RFC 2965, Oct. 2000, 26 pages. • K. Moore, N. Freed: Use of HTTP State Management. RFC 2964, Oct. 2000, 8 pages. • David M. Kristol: HTTP Cookies: Standards, privacy, and politics. ACM Transactions on Internet Technology (TOIT), Volume 1 , Issue 2 (November 2001), Pages: 151 - 198 • S. Brass: Cookies. In R. Flynn (Ed.): Macmillan Computer Sciences. Macmillan, 2002. Stefan Brass: Grundlagen des World Wide Web Universit¨atHalle, 2006 4. The Hypertext Transfer Protocol 4-2 Objectives After completing this chapter, you should be able to: • explain what exactly happens when you click on a link in a web page. You should be able to write HTTP requests and interpret HTTP responses. Why it is good to keep the TCP connection open for a short time after the response? • explain how language and format are selected. • explain authentication for protected pages. -
Specification of Web Ingest of Meteorological Bulletins in Wis
SPECIFICATION OF WEB INGEST OF METEOROLOGICAL BULLETINS IN WIS 2013‐07‐10 TOYODA Eizi, JMA 2013‐09‐09 1st revision, TOYODA Eizi, JMA 2013‐12‐24 2nd revision, MIZUSHIMA Hirofumi, JMA INTRODUCTION This document describes a mechanism to ingest meteorological bulletins in WIS via HTTPS (HTTP over TLS)1. The objective is to back up the dissemination of GTS bulletins when the primary way is under interruptions. The purpose and protocol look similar to the Web Data Ingest2 of GTS. The difference is that the present document is intended for automated submission of files accumulating meteorological bulletins, while the Web Data Ingest is designed for human typing on text forms. GENERAL DISCUSSIONS TERMINOLOGY AND REASON FOR PUSH This document discusses “push” type of protocol, in which sender of data initiates the TCP connection. A software sending data is called “client”, and the receiver called “server”. Push protocol can avoid delay due to polling, while the client has to take responsibility to detect error. The HTTP provides PUT and POST methods for push. Between the two methods, PUT is recommended for simplicity. ONE REQUEST PER ONE FILE One HTTP request is used to submit one file with a name. One HTTP response is returned from the server. The client must inspect the response to detect error. The format of the file may be agreed by both parties of communication, but one possibility is a so‐called WMO FTP format3. 1 IETF RFC 2818: “HTTP Over TLS”. http://tools.ietf.org/html/rfc2818 2 Section B, Attachment II‐16 “Procedures for Transmitting and Collecting Meteorological Bulletins on the Internet”, the Manual on Global Telecommunication System, WMO No. -
Http Status Codes
HTTP STATUS CODES This is a list of Hypertext Transfer Protocol (HTTP) response status codes. 1XX Informational responses An informational response indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response. The message consists only of the status line and optional header fields, and is terminated by an empty line. As the HTTP/1.0 standard did not define any 1xx status codes, servers must not[note 1] send a 1xx response to an HTTP/1.0 compliant client except under experimental conditions.[4] 100 Continue The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. The response 417 Expectation Failed indicates the request should not be continued.[2] 101 Switching Protocols The requester has asked the server to switch protocols and the server has agreed to do so.[5] 102 Processing (WebDAV; RFC 2518) A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.[6] This prevents the client from timing out and assuming the request was lost. -
REST-Style API Reference
DLI REST-style API Reference Generated by Doxygen 20210421T131022Z ii CONTENTS Contents 1 Overview 1 1.1 Target audience............................................ 2 1.2 Design goals.............................................. 2 2 REST architectural style introduction3 2.1 HTTP verbs.............................................. 3 2.2 HTTP request headers ........................................ 4 2.3 Content types............................................. 5 3 Basic examples 5 4 Data model 9 4.1 Scalar types.............................................. 10 4.2 Singleton types ............................................ 10 4.3 Container types............................................ 10 4.4 The sum type ............................................. 11 4.5 The call type.............................................. 11 4.6 Constraints .............................................. 12 5 Supported standard interfaces 12 5.1 URIs.................................................. 12 5.2 HTTP verbs.............................................. 13 5.3 HTTP authentication.......................................... 13 5.4 Input MIME types........................................... 13 5.4.1 application/json........................................ 13 5.4.2 text/plain ........................................... 14 5.4.3 application/x-www-form-urlencoded ............................. 14 5.5 Patch MIME types........................................... 15 5.5.1 application/json-patch+json.................................. 15 5.5.2 application/x-www-form-urlencoded -
An Overview of the HTTP Protocol As Covered in Rfcs 1
An Overview of the HTTP Protocol as covered in RFCs 1 Contents 1. Introduction and History ........................................................................................................................ 3 2. HTTP Versions ......................................................................................................................................... 3 3. HTTP Protocol Request/Response ......................................................................................................... 3 4. HTTP/1.0 and earlier .............................................................................................................................. 4 5. HTTP Keep-Alive ..................................................................................................................................... 4 6. HTTP Pipelining ....................................................................................................................................... 4 7. HTTP ........................................................................................................................................................ 5 8. HTTP Intermediaries: Proxy ................................................................................................................... 5 9. HTTP Intermediaries: Tunnel ................................................................................................................. 6 10. HTTP Methods ....................................................................................................................................... -
Hypertext Transfer Protocol -- HTTP/1.1
Network Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. C. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-Lee W3C/MIT June, 1999 Hypertext Transfer Protocol -- HTTP/1.1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as “HTTP/1.1”, and is an update to RFC 2068 [33]. Fielding, et al Standards Track [Page 1] RFC 2616 HTTP/1.1 June, 1999 Table of Contents HYPERTEXT TRANSFER PROTOCOL -- HTTP/1.1.................................................1 -
Syncml HTTP Binding 1 of 19 Pages Version 1.0 2000-12-07
SyncML HTTP Binding 1 of 19 Pages http://www.syncml.org/docs/syncml_http_v10_20001207.pdf Version 1.0 2000-12-07 SyncML HTTP Binding, version 1.0 Abstract THIS SPECIFICATION IS A SYNCML DRAFT DOCUMENT AND MAY BE UPDATED, REPLACED OR OBSOLETED BY ANOTHER DOCUMENT AT ANY TIME. IT IS INAPPROPRIATE TO USE THIS SPECIFICATION FOR PRODUCT IMPLEMENTATION UNTIL PUBLISHED OR TO REFERENCE THE MATERIAL OR TO CITE IT OTHER THAN AS "WORK IN PROGRESS". This document describes how to use the SyncML over HTTP. The document uses the primitives and methods defined in the HTTP specification V1.1 as defined in [1]. The document assumes a scenario consisting of a data synchronization client (e.g., a mobile phone) and a data synchronization server where the master for the data resides. Within wide area networks, the data synchronization server could be a remote web server. Copyright © Ericsson, IBM, Lotus, Matsushita Communications Industrial Co., LTD, Motorola, Nokia, Palm, Inc., Psion, Starfish Software (2000) All Rights Reserved. SyncML HTTP Binding 2 of 19 Pages http://www.syncml.org/docs/syncml_http_v10_20001207.pdf Version 1.0 2000-12-07 SyncML Initiative The following companies are Sponsors of the SyncML initiative: Ericsson IBM Lotus Matsushita Communications Industrial Co. Motorola Nokia Palm, Inc. Psion Starfish Software Revision History Revision Date Comments V0.9 2000-05-31 Version 0.9. V1.0 2000-08-29 Reformatted for v1.0 Alpha release. No technical changes. Alpha V1.0 Beta 2000-11-10 Revised headers for v1.0 Beta release. No technical changes. V1.0 2000-12-07 The candidate version for the final release.