HTTP Server
The HTTP Server source listens on an HTTP endpoint and processes the contents of all authorized HTTP POST and PUT requests. Use the HTTP Server source to read high volumes of HTTP POST and PUT requests using multiple threads. For information about supported versions, see Supported systems and versions.
The HTTP Server source can read requests containing messages with no compression or with the Gzip or Snappy compression format.
The HTTP Server source can use multiple threads to enable parallel processing of data from multiple HTTP clients. The source can require that requests specify an allowed application ID. Before you run a flow with the source, perform additional steps to configure the HTTP clients.
When a flow stops, the HTTP Server source notes where it stops reading. When the flow starts again, the source continues processing from where it stopped by default. You can reset the offset to process all requested data.
When you configure the HTTP Server source, you specify the maximum number of concurrent requests to determine how many threads to use. You define the listening port, allowed application IDs, and the maximum message size. You can also configure SSL/TLS properties, including default transport protocols and cipher suites.
The source provides request header fields as record header attributes so you can use the information in the flow when needed.
Prerequisites
Before you run a flow with the HTTP Server source, complete the following prerequisites to configure the HTTP clients.
Send data to the listening port
Configure the HTTP clients to send data to the HTTP Server listening port.
When you configure the source, you define a listening port number where the source listens for data. To pass data to the flow, configure each HTTP client to send data to a URL that includes the listening port number.
<http | https>://<sdc_hostname>:<listening_port>/- <http | https> - Use https for secure HTTP connections.
- <sdc_hostname> - The Data Collector host name.
- <listening_port> - The port number where the source listens for data.
For example: https://localhost:8000/
Include the application ID in requests
For sources configured to require requests from allowed application IDs, configure the HTTP clients to include an allowed application ID in each request.
When you configure the HTTP Server source, you can optionally define a list of application IDs allowed to pass requests to the source. If you specify a list of application IDs, then all messages sent to the source must include one of the specified application IDs.
Client requests can include the application ID in one of the following ways:
- In request headers
- Add the following information to the request header for all HTTP requests that
you want the source to
process:
X-SDC-APPLICATION-ID: <application_ID> - In a query parameter in the URL
- If you cannot configure the client request headers - for example if the requests are generated by another system - then configure each HTTP client to send data to a URL that includes the application ID in a query parameter.
Multithreaded processing
The HTTP Server source can use multiple threads to perform parallel processing based on the Max Concurrent Requests property.
When you start a multithreaded flow, the source creates the number of threads specified in the Max Concurrent Requests property. Each thread generates a batch from an incoming request and passes the batch to an available flow runner.
A flow runner is a sourceless flow instance - an instance of the flow that includes all of the processors, executors, and targets in the flow and handles all flow processing after the source. Each flow runner processes one batch at a time, just like a flow that runs on a single thread. When the flow of data slows, the flow runners wait idly until they are needed, generating an empty batch at regular intervals. You can configure the Runner Idle Time flow property to specify the interval or to opt out of empty batch generation.
Multithreaded flows preserve the order of records within each batch, just like a single-threaded flow. But since batches are processed by different flow runners, the order that batches are written to targets is not ensured.
For example, say you set the Max Concurrent Requests property to 5. When you start the flow, the source creates five threads, and Data Collector creates a matching number of flow runners. Upon receiving data, the source passes a batch to each of the flow runners for processing. In the batch, HTTP Server includes only the HTTP POST and PUT requests with the specified Application ID.
Each flow runner performs the processing associated with the rest of the flow. After a batch is written to flow targets, the flow runner becomes available for another batch of data. Each batch is processed and written as quickly as possible, independent from other batches processed by other flow runners, so batches may be written differently from the read order.
At any given moment, the five flow runners can each process a batch, so this multithreaded flow processes up to five batches at a time. When incoming data slows, the flow runners sit idle, available for use as soon as the data flow increases.
For more information about multithreaded flows, see Multithreaded flow overview.
Data formats
The HTTP Server source processes data differently based on the data format that you select.
The HTTP Server source processes data formats as follows:
- Avro
- Generates a record for every Avro record. The source includes the Avro schema in the
avroSchemarecord header attribute. It also includes aprecisionandscalefield attribute for each Decimal field. - Binary
- Generates a record with a single byte array field at the root of the record.
- Datagram
- Generates a record for every message. The source can process collectd messages, NetFlow 5 and NetFlow 9 messages, and the following types of syslog messages:
- Delimited
- Generates a record for each delimited line.
- JSON
- Generates a record for each JSON object. You can process JSON files that include multiple JSON objects or a single JSON array.
- Protobuf
- Generates a record for every protobuf message. By default, the source assumes messages contain multiple protobuf messages.
- SDC Record
- Generates a record for every record. Use to process records generated by a Data Collector flow using the SDC Record data format.
- XML
- Generates records based on a user-defined delimiter element. Use an XML element directly under the root element or define a simplified XPath expression. If you do not define a delimiter element, the source treats the XML file as a single record.
Record header attributes
The REST Service source creates record header attributes that include information about the requested URL.
You can use the record:attribute or
record:attributeOrDefault functions to access the information
in the attributes. For more information about working with record header attributes,
see Working with header attributes.
- method - The HTTP method for the request, such as GET, POST, or DELETE.
- path - The path of the URL.
- queryString - The parameters of the URL that come after the path. Can be empty if there are no query parameters on the URL.
- remoteHost - The name of the client or proxy that made the request.
The HTTP Server source also includes HTTP request header fields – such as Host or Content-Type – in records as record header attributes. The attribute names match the original HTTP request header field name.
Configuring an HTTP Server source
About this task
Configure an HTTP Server source to generate multiple threads for parallel processing of HTTP POST and PUT requests.