<?xml version="1.0" encoding="UTF-8" standalone="no"?> <xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/http" xmlns:mule="http://www.mulesoft.org/schema/mule/core" xmlns:schemadoc="http://www.mulesoft.org/schema/mule/schemadoc" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:tcp="http://www.mulesoft.org/schema/mule/tcp" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import namespace="http://www.mulesoft.org/schema/mule/core" schemaLocation="http://www.mulesoft.org/schema/mule/core/3.1/mule.xsd"/> <xsd:import namespace="http://www.mulesoft.org/schema/mule/tcp" schemaLocation="http://www.mulesoft.org/schema/mule/tcp/3.1/mule-tcp.xsd"/> <xsd:import namespace="http://www.mulesoft.org/schema/mule/schemadoc" schemaLocation="http://www.mulesoft.org/schema/mule/schemadoc/3.1/mule-schemadoc.xsd"/> <xsd:annotation> <xsd:documentation> The HTTP transport provides support for exposing services over HTTP and making HTTP client requests from Mule services to external services as part of service event flows. Mule supports inbound, outbound, and polling HTTP endpooints. These endpoints support all common features of the HTTP spec, such as ETag processing, cookies, and keepalive. Both HTTP 1.0 and 1.1 are supported. </xsd:documentation> <xsd:appinfo> <schemadoc:short-name>HTTP</schemadoc:short-name> <schemadoc:page-title>HTTP Transport</schemadoc:page-title> <schemadoc:transport-features dispatchEvents="true" receiveEvents="true" requestEvents="true" streaming="true" transactions="false"> <schemadoc:MEPs default="request-response" supported="one-way, request-response"/> </schemadoc:transport-features> </xsd:appinfo> </xsd:annotation> <xsd:annotation> <xsd:documentation> Allows Mule to communicate over HTTP. All parts of the HTTP spec are covered by Mule, so you can expect ETags to be honored as well as keep alive semantics and cookies. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="polling-connector" substitutionGroup="mule:abstract-connector" type="httpPollingConnectorType"> <xsd:annotation> <xsd:documentation> Allows Mule to poll an external HTTP server and generate events from the result. This is useful for pull-only web services. </xsd:documentation> </xsd:annotation> </xsd:element> <!-- NOTE - it's not very easy to work out what parameters inherited from TCP are actually used. But it appears that the client parameters are used to set the HttpConnectionManager while the server parameters are used directly (the server socket appears to come from the underlying TcpConnector). --> <xsd:complexContent> <xsd:annotation> <xsd:documentation> The cookie specification to be used by this connector when cookies are enabled. </xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="netscape"/> <xsd:enumeration value="rfc2109"/> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:annotation> <xsd:documentation> The proxy host name or address. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> The password to use for proxy access. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> The proxy port number. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> The username to use for proxy access. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> Whether to support cookies. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexContent> <xsd:annotation> <xsd:documentation> The time in milliseconds to wait between each request to the remote HTTP server. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> Whether the ETag header from the remote server is processed if the header is present. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> Whether Mule should discard any messages from the remote server that have a zero content length. For many services a zero length would mean there was no data to return. If the remote HTTP server does return content to say that that the request is empty, users can configure a content filter on the endpoint to filter these messages out. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="rest-service-component" substitutionGroup="mule:abstract-component" type="restServiceWrapperType"> <xsd:annotation> <xsd:documentation> Built-in RestServiceWrapper can be used to proxy REST style services as local Mule components. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> An error filter can be used to detect whether the response from the remote service resulted in an error. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:annotation> <xsd:documentation> If the payload of the message is to be attached as a URL parameter, this should be set to the parameter name. If the message payload is an array of objects that multiple parameters can be set to, use each element in the array. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> These are parameters that must be available on the current message for the request to be successful. The Key maps to the parameter name, the value can be any one of the valid expressions supported by Mule. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> These are parameters that if they are on the current message will be added to the request, otherwise they will be ignored. The Key maps to the parameter name, the value can be any one of the valid expressions supported by Mule. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:annotation> <xsd:documentation> The HTTP method to use when making the service request. </xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="DELETE"/> <xsd:enumeration value="GET"/> <xsd:enumeration value="POST"/> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:annotation> <xsd:documentation> The service URL to use when making the request. This should not contain any parameters, since these should be configured on the component. The service URL can contain Mule expressions, so the URL can be dynamic for each message request. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- TODO MULE-3439: this should be renamed to http-response-to-message --> <xsd:element name="http-response-to-object-transformer" substitutionGroup="mule:abstract-transformer" type="mule:abstractTransformerType"> <xsd:annotation> <xsd:documentation> A transformer that converts an HTTP response to a Mule Message. The payload may be a String, stream, or byte array. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="http-response-to-string-transformer" substitutionGroup="mule:abstract-transformer" type="mule:abstractTransformerType"> <xsd:annotation> <xsd:documentation> Converts an HTTP response payload into a string. The headers of the response will be preserved on the message. </xsd:documentation> </xsd:annotation> </xsd:element> <!-- TODO: MULE-3440 rename to object-to-http-request-transformer --> <xsd:element name="object-to-http-request-transformer" substitutionGroup="mule:abstract-transformer" type="mule:abstractTransformerType"> <xsd:annotation> <xsd:documentation> This transformer will create a valid HTTP request using the current message and any HTTP headers set on the current message. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="message-to-http-response-transformer" substitutionGroup="mule:abstract-transformer" type="mule:abstractTransformerType"> <xsd:annotation> <xsd:documentation> This transformer will create a valid HTTP response using the current message and any HTTP headers set on the current message. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="body-to-parameter-map-transformer" substitutionGroup="mule:abstract-transformer" type="mule:abstractTransformerType"> <xsd:annotation> <xsd:documentation> This transformer parses the body of a HTTP request into a Map. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="inbound-endpoint" substitutionGroup="mule:abstract-inbound-endpoint" type="inboundEndpointType"> <xsd:annotation> <xsd:documentation> An inbound HTTP endpoint exposes a service over HTTP, essentially making it an HTTP server. If polling of a remote HTTP service is required, this endpoint should be configured with a polling HTTP connector. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:complexContent> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="outbound-endpoint" substitutionGroup="mule:abstract-outbound-endpoint" type="outboundEndpointType"> <xsd:annotation> <xsd:documentation> The HTTP outbound endpoint allows Mule to send requests to external servers or Mule inbound HTTP endpoints using the HTTP protocol. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:complexContent> <xsd:annotation> <xsd:documentation> If a request if made using GET that responds with a redirectLocation header, setting this to true will make the request on the redirect URL. This only works when using GET since you cannot automatically follow redirects when perfroming a POST (a restriction according to RFC 2616). </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="endpoint" substitutionGroup="mule:abstract-global-endpoint" type="globalEndpointType"> <xsd:annotation> <xsd:documentation> Configures a 'global' HTTP endpoint that can be referenced by services. Services can augment the configuration defined in the global endpoint with local configuration elements. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:complexContent> <xsd:annotation> <xsd:documentation> If a request if made using GET that responds with a redirectLocation header, setting this to true will make the request on the redirect URL. This only works when using GET since you cannot automatically follow redirects when perfroming a POST (a restriction according to RFC 2616). </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> The user name (if any) that will be used to authenticate against. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation>The password for the user.</xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> The host to connect to. For inbound endpoints, this should be an address of a local network interface. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation>The port number to use when a connection is made.</xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation>The path for the HTTP URL.</xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:attributeGroup> <!-- maybe we mant a more general mechanism, perhaps an element for header values? --> <xsd:annotation> <xsd:documentation>The HTTP ContentType to use.</xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation>The HTTP method to use.</xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> Controls if the socket connection is kept alive. If set to true, a keep-alive header with the connection timeout specified in the connector will be returned. If set to false, a "Connection: close" header will be returned. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:attributeGroup> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="OPTIONS"/> <xsd:enumeration value="GET"/> <xsd:enumeration value="HEAD"/> <xsd:enumeration value="POST"/> <xsd:enumeration value="PUT"/> <xsd:enumeration value="TRACE"/> <xsd:enumeration value="CONNECT"/> <xsd:enumeration value="DELETE"/> </xsd:restriction> </xsd:simpleType> <xsd:element name="request-wildcard-filter" substitutionGroup="mule:abstract-filter" type="mule:wildcardFilterType"> <xsd:annotation> <xsd:documentation> (As of 2.2.2) The request-wildcard-filter element can be used to restrict the request by applying wildcard expressions to the URL. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:schema> |
XML schema documentation generated with DocFlex/XML SDK 1.8.1b6 using DocFlex/XML XSDDoc 2.2.1 template set. All content model diagrams generated by Altova XMLSpy via DocFlex/XML XMLSpy Integration. |