a909c6f6d36bc5a31c88df58800c2f27.ppt
- Количество слайдов: 21
From Extensibility to Evolvability Once upon a time, HTTP was simple – what happened? Fri, 8 October 1999
Overview of Talk n What makes an extension? n n In the good old days, HTTP was simple n n Why did it get complex? HTTP is already quite extensible n n And why extend in the first place? Why isn’t this enough? What is Evolvability? n How can we support it? Fri, 8 October 1999 2
Why Extensions? n Why not just a fixed set of features? n n n Would be a lot easier Doesn’t work because… Extensions are fundamental to the Web n The Web is an information space n n Not a single service Every one lives in the same information space How you live there is up to you Change of Focus n From creating infrastructure to creating services using that infrastructure Fri, 8 October 1999 3
What is an Extension? n Qualification of a normal HTTP message n n New HTTP syntax and encoding n n Web. DAV, etc. HTTP-like protocols for new applications n n Sticky headers, binary encoding etc. Extensions to the “HTTP application” n n authentication, payment, etc. RTSP, IMAP etc. Leaving HTTP and TCP entirely n Multicast etc. Fri, 8 October 1999 4
Once Upon a Time. . . n n HTTP started out as a simple hypertext protocol Send GET request - get back a document n n There was no information about the document you retrieved n n Hypertext was what you asked for and what you got Especially no content-type This were the early days of HTTP/0. 9 Fri, 8 October 1999 5
Then HTTP/1. 0 came along n n n No more only text based documents Needed type information to distinguish images from text MIME provided a mechanism for describing protocol messages n n Was adopted for describing HTTP messages A major cross road on the evolutionary path Fri, 8 October 1999 6
And Much More Followed… n Large number of added features n n n n n Byte ranges Cookies Content negotiation Authentication and proxy authentication Proxying, caching, and gateways Hit metering Persistent connections and pipelining … Pattern has been copied in RTSP, SIP etc. Fri, 8 October 1999 7
Thanks to HTTP’s Architecture n All these extensions could fit into HTTP n n Request Method (one pr message) n n GET, HEAD, POST, DELETE, etc. Response Status Code (one pr message) n n Using the basic HTTP building blocks… 1 xx, 2 xx, 3 xx, 4 xx, 5 xx, etc. Header Fields (many pr message) n Protocol headers n n Upgrade, User-Agent, Accept, Date, Server, etc. Entity Headers n Content-Length, Content-Encoding, etc. Fri, 8 October 1999 8
The Good Part… n n What are the lessons so far? The good side of all these extensions: n n n Several of them have become widespread n n n HTTP could actually support them The extensions provide very useful features Even across trust domains! Thanks to the IETF WG HTTP is really quite extensible Fri, 8 October 1999 9
And the Bad Part… n All these extensions had to be part of the base protocol n n Cost has been a very complex protocol n n Have blurred the (already implicit) line between base protocol and extensions in HTTP/1. 1 has been under way a long time Not just result of complex extensions but how they interact Adding new features gets harder and harder Reason: No way of replacing existing features n n Cost of backwards compatibility keeps increasing Will never be able to replace existing features Fri, 8 October 1999 10
Extensibility vs Evolvability n Cost pr feature increases over time Extensibility: n Evolvability: n Fri, 8 October 1999 11
Interoperability vs. Evolvability n Cost of evolvability: n As evolvability goes up, ease of deployment goes down Fri, 8 October 1999 12
Supporting Evolvability n How are Extensions deployed in the Web? n n n This means that: n n Often by extending existing applications Spreading from in the small to the large over time Applications have different capabilities at all times This requires that: n n n Applications supporting a particular extension should be able to employ this with no prior agreement; Applications can require that the other party either understand abide by the new protocol or abort the operation; Has to work with existing HTTP Fri, 8 October 1999 13
The Four Rules of Evolvability n Can be accomplished by expressing these four parameters as part of the protocol: n What it is (identify extension) n n n How to deal with it (optional or mandatory) n n Can recipient ignore it or not? Who should deal with it (hop-by-hop or end-2 -end) n n A URI identifies the extension in the global URI space May be resolvable (interface description, code, etc. ) Should this go to the proxy or the user-agent, origin server When to deal with it (ordering) n First do this; then do this etc. Fri, 8 October 1999 14
HTTP Extension Framework n Mechanism for lowering cost of extensions n n n Works with existing HTTP Stable specification ready to be used Fulfills the 4 rules through support for n Decentralized deployment based on n Evolution through mandatory declarations n n You can’t ignore this extension Separation of end-2 -end and hop-by-hop extensions n n URIs for identification No risk of collisions between methods, status codes, or header fields Allows Ordering of extensions Fri, 8 October 1999 15
Example of Mandatory Ext. M-POST http: //www. buy. com/payment HTTP/1. 1 Man: "http: //www. ecommerce. org/ext/payment" … <parameters describing your payment> HTTP/1. 1 200 OK Ext: Date: Sun, 25 Oct 1998 08: 12: 31 GMT … Fri, 8 October 1999 16
Example of Optional Ext. GET http: //www. somesite. com/some. doc HTTP/1. 1 Opt: "http: //www. webalizer. org/ext/hitcount" … HTTP/1. 1 200 OK Opt: "http: //www. webalizer. org/ext/hitcount"; ns=12 12 -hitcount: 24 Cache-Control: no-cache="12 -hitcount, Opt" Date: Sun, 25 Oct 1998 08: 12: 31 GMT Expires: Sun, 25 Oct 1998 08: 12: 31 GMT … Fri, 8 October 1999 17
Extension Declaration Params n What it is (identify extension) n n n How to deal with it n n optional or mandatory Who should deal with it n n The URI of the extension points to a definition of that extension This can be a formal interface description, a piece of code, a textual description, or nothing at all (may not be resolvable) hop-by-hop or end-2 -end When to deal with it n ordering Fri, 8 October 1999 18
Extension Declarations n n Use the header field space for declaring extensions This means that declarations can n Float between Methods Float between Status Codes Can be applied to any HTTP request/response n Few exceptions like 304 (Not Modified) Fri, 8 October 1999 19
Server Response n When a server sees an extended message it can respond with n 510 (Not extended) n n n 2 xx (OK in some form) n n Message did not contain the information I needed. This can either be parameters or extensions Client can then try again if it wants to Request succeeded and extension was dealt with Any other HTTP code n In case it is covered by HTTP already Fri, 8 October 1999 20
Client Response n When a client sees an extended response, it can n n Ignore optional extension declarations or deal with them if it wants to The server can only send mandatory extensions in a response if it knows that the client has some way of dealing with it n n For example if it has asked for a mandatory extension. The client can then retry the request with extensions included, or go away and forget about it Fri, 8 October 1999 21
a909c6f6d36bc5a31c88df58800c2f27.ppt