Add protocol for handling Request & Response

Many modern Java Web Server (Netty, Undertow, Vert.x) have their own abstractions for Requests and Responses. Current ring-spec states that requests and responses as map-like structures. While this is awesome in abstraction-wise (and the killer feature of Ring), performance-wise it can be bad as data needs to be copied into maps. Copying can be eager (like with the jetty-adapter) for all requests or lazy (like Aleph & Immutant) / on demand, but still things like accessing a single header value forced all headers to be read copied and keys lowercased.

Abstracting the request and response as protocols would allow best of both worlds. A protocol like:

(defprotocol RingRequest
  (get-server-port [this])
  (get-server-name [this])
  (get-remote-addr [this])
  (get-uri [this])
  (get-query-string [this])
  (get-scheme [this])
  (get-request-method [this])
  (get-protocol [this])
  (get-headers [this])
  (get-header [this header])
  (get-body [this])
  (get-context [this]))

could be implemented for maps so that they do the normal lookup, but the Aleph-style zero-copy-request (map-like) classes could implement those directly. (get-header request "Content-Type") would use the already parsed information without any copying.

This would allow low-level libraries to be programmed against effective protocols while keeping everything compatible with maps.

Currently working on a new lightweight and zero-fat new wrapper for Undertow and using a custom request protocol (like the one above) with it, but would not like to tie our other libraries to a server-specific protocols.

All the current web servers having their own request & response (map-like) types would need to conform to the new protocols, so would be a breaking change.

Start by reviewing the current ring-spec and the request/response handling in the Jetty adapter, Aleph, and Immutant mentioned in the issue. Compare those interfaces with the proposed RingRequest protocol and the Undertow wrapper context. Done would require an agreed protocol design, compatible implementations for existing server types, and a documented plan for the breaking change.