sledge/runtime/include/http_response.h

#ifndef SFRT_HTTP_RESPONSE_H
#define SFRT_HTTP_RESPONSE_H

#include <http_parser.h>
#include <types.h>
#include <sys/uio.h>

// Conditionally load libuv
#ifdef USE_HTTP_UVIO
#include <uv.h>
#endif

struct http_response_header {
	char *header;
	int   length;
};

struct http_response {
	struct http_response_header headers[HTTP__MAX_HEADER_COUNT];
	int                         header_count;
	char *                      body;
	int                         body_length;
	char *                      status;
	int                         status_length;
#ifdef USE_HTTP_UVIO
	uv_buf_t bufs[HTTP__MAX_HEADER_COUNT * 2 + 3]; // max headers, one line for status code, remaining for body!
#else
	struct iovec bufs[HTTP__MAX_HEADER_COUNT * 2 + 3];
#endif
};

/***************************************************
 * General HTTP Response Functions                 *
 **************************************************/
int http_response_encode_as_vector(struct http_response *http_response);
int http_response_set_body(struct http_response *http_response, char *body, int length);
int http_response_set_header(struct http_response *http_response, char *h, int length);
int http_response_set_status(struct http_response *http_response, char *status, int length);

#endif /* SFRT_HTTP_RESPONSE_H */
chore: decompose http 5 years ago			`#ifndef SFRT_HTTP_RESPONSE_H`
			`#define SFRT_HTTP_RESPONSE_H`
http request response using uv 5 years ago
			`#include <http_parser.h>`
			`#include <types.h>`
Synchronous I/O for http request/response fixes 99%tile latencies * Async I/O is being used for reading and writing http request and response respectively. This causes the worker core to steal new tasks as when one sandbox blocks on "read" or "write". This causes true round-robin on timer interrupts, leading to those high latencies. * Ideally, the request/response should be synchronous I belive because we are expected to have "low"/near-realtime latencies and the read/writes are only performed when a client connects, so ideally not block! Plus, we expect only small data transfers (in KBs) so that should also support synchronous request/response processing. 5 years ago			`#include <sys/uio.h>`
http request response using uv 5 years ago
chore: cleanup http 5 years ago			`// Conditionally load libuv`
			`#ifdef USE_HTTP_UVIO`
			`#include <uv.h>`
			`#endif`

chore: complete HTTP cleanup 5 years ago			`struct http_response_header {`
			`char *header;`
			`int length;`
http request response using uv 5 years ago			`};`

			`struct http_response {`
chore: namespace macros and globals in main.c 5 years ago			`struct http_response_header headers[HTTP__MAX_HEADER_COUNT];`
chore: assorted refactors 5 years ago			`int header_count;`
			`char * body;`
			`int body_length;`
			`char * status;`
			`int status_length;`
Synchronous I/O for http request/response fixes 99%tile latencies * Async I/O is being used for reading and writing http request and response respectively. This causes the worker core to steal new tasks as when one sandbox blocks on "read" or "write". This causes true round-robin on timer interrupts, leading to those high latencies. * Ideally, the request/response should be synchronous I belive because we are expected to have "low"/near-realtime latencies and the read/writes are only performed when a client connects, so ideally not block! Plus, we expect only small data transfers (in KBs) so that should also support synchronous request/response processing. 5 years ago			`#ifdef USE_HTTP_UVIO`
chore: namespace macros and globals in main.c 5 years ago			`uv_buf_t bufs[HTTP__MAX_HEADER_COUNT * 2 + 3]; // max headers, one line for status code, remaining for body!`
Synchronous I/O for http request/response fixes 99%tile latencies * Async I/O is being used for reading and writing http request and response respectively. This causes the worker core to steal new tasks as when one sandbox blocks on "read" or "write". This causes true round-robin on timer interrupts, leading to those high latencies. * Ideally, the request/response should be synchronous I belive because we are expected to have "low"/near-realtime latencies and the read/writes are only performed when a client connects, so ideally not block! Plus, we expect only small data transfers (in KBs) so that should also support synchronous request/response processing. 5 years ago			`#else`
chore: namespace macros and globals in main.c 5 years ago			`struct iovec bufs[HTTP__MAX_HEADER_COUNT * 2 + 3];`
Synchronous I/O for http request/response fixes 99%tile latencies * Async I/O is being used for reading and writing http request and response respectively. This causes the worker core to steal new tasks as when one sandbox blocks on "read" or "write". This causes true round-robin on timer interrupts, leading to those high latencies. * Ideally, the request/response should be synchronous I belive because we are expected to have "low"/near-realtime latencies and the read/writes are only performed when a client connects, so ideally not block! Plus, we expect only small data transfers (in KBs) so that should also support synchronous request/response processing. 5 years ago			`#endif`
http request response using uv 5 years ago			`};`

chore: cleanup http 5 years ago			`/***************************************************`
			`* General HTTP Response Functions *`
			`**************************************************/`
chore: de-dunder http_response 5 years ago			`int http_response_encode_as_vector(struct http_response *http_response);`
			`int http_response_set_body(struct http_response http_response, char body, int length);`
			`int http_response_set_header(struct http_response http_response, char h, int length);`
			`int http_response_set_status(struct http_response http_response, char status, int length);`
chore: cleanup http 5 years ago
chore: decompose http 5 years ago			`#endif /* SFRT_HTTP_RESPONSE_H */`