------------------------------------------------------------------------------- |-- Module : Network.HTTP-- Copyright : (c) Warrick Gray 2002, Bjorn Bringert 2003-2005, 2007 Robin Bate Boerop-- License : BSD-- -- Maintainer : Sigbjorn Finne <sigbjorn.finne@gmail.com>-- Stability : experimental-- Portability : non-portable (not tested)---- The 'Network.HTTP' module provides a simple interface for sending and-- receiving content over HTTP in Haskell. Here's how to fetch a document from-- a URL and return it as a String:---- >-- > simpleHTTP (getRequest "http://www.haskell.org/") >>= fmap (take 100) . getResponseBody-- > -- fetch document and return it (as a 'String'.)---- Other functions let you control the submission and transfer of HTTP-- 'Request's and 'Response's more carefully, letting you integrate the use-- of 'Network.HTTP' functionality into your application.---- The module also exports the main types of the package, 'Request' and 'Response',-- along with 'Header' and functions for working with these.---- The actual functionality is implemented by modules in the @Network.HTTP.*@-- namespace, letting you either use the default implementation here-- by importing @Network.HTTP@ or, for more specific uses, selectively-- import the modules in @Network.HTTP.*@. To wit, more than one kind of-- representation of the bulk data that flows across a HTTP connection is -- supported. (see "Network.HTTP.HandleStream".)-- -- /NOTE:/ The 'Request' send actions will normalize the @Request@ prior to transmission.-- Normalization such as having the request path be in the expected form and, possibly,-- introduce a default @Host:@ header if one isn't already present. If you do not -- want the requests tampered with, but sent as-is, please import and use the-- the "Network.HTTP.HandleStream" or "Network.HTTP.Stream" modules instead. They-- export the same functions, but leaves construction and any normalization of -- @Request@s to the user.-------------------------------------------------------------------------------moduleNetwork.HTTP(moduleNetwork.HTTP.Base,moduleNetwork.HTTP.Headers{- the functionality that the implementation modules,
Network.HTTP.HandleStream and Network.HTTP.Stream,
exposes:
-},simpleHTTP-- :: Request -> IO (Result Response),simpleHTTP_-- :: Stream s => s -> Request -> IO (Result Response),sendHTTP-- :: Stream s => s -> Request -> IO (Result Response),sendHTTP_notify-- :: Stream s => s -> Request -> IO () -> IO (Result Response),receiveHTTP-- :: Stream s => s -> IO (Result Request),respondHTTP-- :: Stream s => s -> Response -> IO (),moduleNetwork.TCP,getRequest-- :: String -> Request_String,postRequest-- :: String -> Request_String,getResponseBody-- :: Requesty ty -> ty)where----------------------------------------------------------------------------------- Imports -------------------------------------------------------------------------------------------------------importNetwork.HTTP.HeadersimportNetwork.HTTP.BaseimportqualifiedNetwork.HTTP.HandleStreamasS-- old implementation: import Network.HTTP.StreamimportNetwork.TCPimportNetwork.Stream(Result)importNetwork.URI(parseURI)importData.Maybe(fromMaybe){-
Note: if you switch over/back to using Network.HTTP.Stream here, you'll
have to wrap the results from 'openStream' as Connections via 'hstreamToConnection'
prior to delegating to the Network.HTTP.Stream functions.
-}-- | @simpleHTTP req@ transmits the 'Request' @req@ by opening a /direct/, non-persistent-- connection to the HTTP server that @req@ is destined for, followed by transmitting-- it and gathering up the response as a 'Result'. Prior to sending the request,-- it is normalized (via 'normalizeRequest'). If you have to mediate the request-- via an HTTP proxy, you will have to normalize the request yourself. Or switch to-- using 'Network.Browser' instead.---- Examples:---- > simpleHTTP (getRequest "http://hackage.haskell.org/")-- > simpleHTTP (getRequest "http://hackage.haskell.org:8012/")simpleHTTP::(HStreamty)=>Requestty->IO(Result(Responsety))simpleHTTPr=doauth<-getAuthrc<-openStream(hostauth)(fromMaybe80(portauth))letnorm_r=normalizeRequestdefaultNormalizeRequestOptions{normDoClose=True}rsimpleHTTP_cnorm_r-- | Identical to 'simpleHTTP', but acting on an already opened stream.simpleHTTP_::HStreamty=>HandleStreamty->Requestty->IO(Result(Responsety))simpleHTTP_sr=doletnorm_r=normalizeRequestdefaultNormalizeRequestOptions{normDoClose=True}rS.sendHTTPsnorm_r-- | @sendHTTP hStream httpRequest@ transmits @httpRequest@ (after normalization) over-- @hStream@, but does not alter the status of the connection, nor request it to be-- closed upon receiving the response.sendHTTP::HStreamty=>HandleStreamty->Requestty->IO(Result(Responsety))sendHTTPconnrq=doletnorm_r=normalizeRequestdefaultNormalizeRequestOptionsrqS.sendHTTPconnnorm_r-- | @sendHTTP_notify hStream httpRequest action@ behaves like 'sendHTTP', but-- lets you supply an IO @action@ to execute once the request has been successfully-- transmitted over the connection. Useful when you want to set up tracing of-- request transmission and its performance.sendHTTP_notify::HStreamty=>HandleStreamty->Requestty->IO()->IO(Result(Responsety))sendHTTP_notifyconnrqonSendComplete=doletnorm_r=normalizeRequestdefaultNormalizeRequestOptionsrqS.sendHTTP_notifyconnnorm_ronSendComplete-- | @receiveHTTP hStream@ reads a 'Request' from the 'HandleStream' @hStream@receiveHTTP::HStreamty=>HandleStreamty->IO(Result(Requestty))receiveHTTPconn=S.receiveHTTPconn-- | @respondHTTP hStream httpResponse@ transmits an HTTP 'Response' over-- the 'HandleStream' @hStream@. It could be used to implement simple web-- server interactions, performing the dual role to 'sendHTTP'.respondHTTP::HStreamty=>HandleStreamty->Responsety->IO()respondHTTPconnrsp=S.respondHTTPconnrsp-- | @getRequest urlString@ is convenience constructor for basic GET 'Request's. If-- @urlString@ isn't a syntactically valid URL, the function raises an error.getRequest::String->Request_StringgetRequesturlString=caseparseURIurlStringofNothing->error("getRequest: Not a valid URL - "++urlString)Justu->mkRequestGETu-- | @postRequest urlString@ is convenience constructor for POST 'Request's. If-- @urlString@ isn\'t a syntactically valid URL, the function raises an error.postRequest::String->Request_StringpostRequesturlString=caseparseURIurlStringofNothing->error("postRequest: Not a valid URL - "++urlString)Justu->mkRequestPOSTu-- | @getResponseBody response@ takes the response of a HTTP requesting action and-- tries to extricate the body of the 'Response' @response@. If the request action-- returned an error, an IO exception is raised.getResponseBody::Result(Responsety)->IOtygetResponseBody(Lefterr)=fail(showerr)getResponseBody(Rightr)=return(rspBodyr)---- * TODO-- - request pipelining-- - https upgrade (includes full TLS, i.e. SSL, implementation)-- - use of Stream classes will pay off-- - consider C implementation of encryption\/decryption-- - comm timeouts-- - MIME & entity stuff (happening in separate module)-- - support \"*\" uri-request-string for OPTIONS request method-- -- -- * Header notes:---- [@Host@]-- Required by HTTP\/1.1, if not supplied as part-- of a request a default Host value is extracted-- from the request-uri.-- -- [@Connection@] -- If this header is present in any request or-- response, and it's value is "close", then-- the current request\/response is the last -- to be allowed on that connection.-- -- [@Expect@]-- Should a request contain a body, an Expect-- header will be added to the request. The added-- header has the value \"100-continue\". After-- a 417 \"Expectation Failed\" response the request-- is attempted again without this added Expect-- header.-- -- [@TransferEncoding,ContentLength,...@]-- if request is inconsistent with any of these-- header values then you may not receive any response-- or will generate an error response (probably 4xx).------ * Response code notes-- Some response codes induce special behaviour:---- [@1xx@] \"100 Continue\" will cause any unsent request body to be sent.-- \"101 Upgrade\" will be returned.-- Other 1xx responses are ignored.-- -- [@417@] The reason for this code is \"Expectation failed\", indicating-- that the server did not like the Expect \"100-continue\" header-- added to a request. Receipt of 417 will induce another-- request attempt (without Expect header), unless no Expect header-- had been added (in which case 417 response is returned).