Простой HTTP-сервер не пишет ответ клиенту

Я пишу простой HTTP сервер на C из конкурса CodeCrafter Создайте свой собственный HTTP-сервер. Запрос, к которому я обращаюсь, следующий:

Затем тестер отправит два HTTP запроса на ваш сервер.

Сначала тестер отправит запрос GET со случайной строкой в ​​качестве пути:

$ curl -v http://localhost:4221/abcdefg Ваш сервер должен ответить на этот запрос кодом 404:

HTTP/1.1 404 Не найден\r\n\r\n

Затем тестер отправит GET запрос с путем /: $ curl -v http://localhost:4221 Ваш сервер должен ответить на этот запрос ответом 200:

HTTP/1.1 200 ОК\r\n\r\n

Для чтения/записи я использовал пакет Rio, написанный в разделе Компьютерные системы: взгляд программиста. Функции чтения вроде работают нормально, так как клиентский запрос читается правильно, однако запись не работает.

Тест возвращает мне следующую ошибку:


remote: [tester::#IH0] Sent bytes: "GET /mango HTTP/1.1\r\nHost: localhost:4221\r\n\r\n"
remote: [your_program] Client connected
remote: [tester::#IH0] Failed to read response: 
remote: [tester::#IH0] Received: "" (no content received)
remote: [tester::#IH0]            ^ error
remote: [tester::#IH0] Error: Expected: HTTP-version, Received: ""
remote: [tester::#IH0] Test failed

Полный код:


#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>


# define BUF_SIZE 8192
# define MAX_LINE 4096

/* struct that defines an internal buffer where to read/write avoiding frequent traps to OS */
typedef struct {
    int rio_fd;
    int rio_cnt;
    char buf[BUF_SIZE];
    char *rio_bufptr;
} rio_t;


/* initialize rio_t internal buffer */
void rio_init (rio_t *riot, int fd) {
    riot->rio_fd = fd;
    riot->rio_cnt = 0;
    riot->rio_bufptr = riot->buf;
}

/* buffered version of read(), reads from the internal buffer rio_t -> buf until is not completely consumed */
ssize_t rio_read (rio_t *riot, char *usrbuf, size_t n) {
    int cnt;
    while (riot->rio_cnt <= 0) {
        riot->rio_cnt = read(riot->rio_fd, riot->buf, sizeof(riot->buf));
        if (riot->rio_cnt < 0) {
            if (errno != EINTR) { // sighandler
                return -1;
            } 
        } else if (riot->rio_cnt == 0) { // EOF
            return 0;
        } else {
            // reset buffer
            riot->rio_bufptr = riot->buf;
        }
    }

    cnt = n;
    if (riot->rio_cnt < n) {
        cnt = riot->rio_cnt;
    }
    memcpy(usrbuf, riot->rio_bufptr, cnt);
    riot->rio_bufptr += cnt;
    riot->rio_cnt -= cnt;
    return cnt;
}

/* improved version of read, avoids short count, reads until requested bytes are read (n) or EOF */
size_t rio_readnb (rio_t  *riot, void *usrbuf, size_t n) {
    size_t nleft = n;
    ssize_t nread;
    char *buf = usrbuf;

    while (nleft > 0) {
        nread = rio_read(riot, buf, nleft);
        if (nread < 0) {
            if (errno == EINTR) { // interrupted by sighandler, call read() again
                nread = 0;
            } else {
                return -1; // error
            }
        } else if (nread == 0)  { // EOF
            break;
        }
        nleft -= nread;
        buf += nread;
    }

    return (n - nleft);
}


/* buffered write, used to avoid dealing with short counts encountered in network applications due to network delay etc. */
ssize_t rio_writen (int fd, void *buf, size_t n) {
    size_t nleft = n;
    ssize_t nwritten;
    char *bufp = buf;

    printf("%s\n", bufp);

    while (nleft > 0) {
        if ((nwritten = write(fd, bufp, nleft)) <= 0) {
            if (errno == EINTR) {
                printf("EINTR.\n");
                nwritten = 0;
            } else {
                printf("Write Error.\n");
                return - 1;
            }
        }
        nleft -= nwritten;
        bufp += nwritten;
    }

    return n;
}


void parseRequest (char *requestBuf, char *responseBuf) {
    char path[MAX_LINE];
    int startPath = 0;
    int i_request = 0;
    int i_path = 0;

    while (requestBuf[i_request] != '\0' && requestBuf[i_request] != '\r' && requestBuf[i_request] != '\n') {
        if (requestBuf[i_request] == ' ') {
            if (startPath) {
                break;  // end of path
            }
        } else {
            if (requestBuf[i_request] == '/') startPath = 1;
            if (startPath) path[i_path++] = requestBuf[i_request];
        }
        i_request++;
    }


    // null terminate
    path[i_path] = '\0';


    if (strcmp(path, "/") == 0) {
        strcpy(responseBuf, "HTTP/1.1 200 OK\r\n\r\n");
    }
    else {
        strcpy(responseBuf, "HTTP/1.1 404 Not Found\r\n\r\n");
    }
}


int main () {
    // Disable output buffering
    setbuf(stdout, NULL);
    setbuf(stderr, NULL);

    // internal buffer to read from client
    rio_t riot;
    // number of bytes read
    size_t n;

    // buffer to read request
    char bufRequest[MAX_LINE];
    char bufResponse[MAX_LINE];

    int server_fd, client_addr_len, conn_fd;
    struct sockaddr_in client_addr;
    
    server_fd = socket(AF_INET, SOCK_STREAM, 0);
    if (server_fd == -1) {
        printf("Socket creation failed: %s...\n", strerror(errno));
        return 1;
    }
    
    // SO_REUSEADDR ensures that we don't run into 'Address already in use' errors
    int reuse = 1;
    if (setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse)) < 0) {
        printf("SO_REUSEADDR failed: %s \n", strerror(errno));
        return 1;
    }
    
    struct sockaddr_in serv_addr = { .sin_family = AF_INET ,
                                     .sin_port = htons(4221),
                                     .sin_addr = { htonl(INADDR_ANY) },
                                    };
    
    if (bind(server_fd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) != 0) {
        printf("Bind failed: %s \n", strerror(errno));
        return 1;
    }
    
    int connection_backlog = 5;
    if (listen(server_fd, connection_backlog) != 0) {
        printf("Listen failed: %s \n", strerror(errno));
        return 1;
    }
    
    printf("Waiting for a client to connect...\n");
    client_addr_len = sizeof(client_addr);
    
    conn_fd = accept(server_fd, (struct sockaddr *) &client_addr, &client_addr_len);
    if (conn_fd == -1) {
        printf("Client not connected, exiting...");
        return 1;
    }

    printf("Client connected\n");

    // initialize internal buffer to read from conn_fd
    rio_init(&riot, conn_fd);
    
    // read request into bufRequest
    while ((n = rio_readnb(&riot, bufRequest, MAX_LINE - 1)) != 0)
        printf("%d bytes read by the server.\n", n);

    
    if (n < 0) {
        printf("Reading failed...\n");
        return 1;
    }

    printf ("The request path is: %s\n", bufRequest);

    parseRequest(bufRequest, bufResponse);

    ssize_t nres = rio_writen(conn_fd, bufResponse, strlen(bufResponse));
    
    close(conn_fd);
    close(server_fd);

    return 0;
}

У вас есть точные данные, которые отправляет тестер. Что мешает вам протестировать на одних и тех же данных? В чем проблема?

n. m. could be an AI 14.06.2024 10:04

Я тестировал с помощью Curl, используя те же данные. Проблема в том, что я получаю пустой ответ от сервера вместо одной из двух строк, которые я должен отправить обратно.

fraari 14.06.2024 10:11

Вы не тестировали с теми же данными. Вы предположили, что тестер закрывает соединение после каждого запроса. Но это не обязательно и не будет.

n. m. could be an AI 14.06.2024 10:33

Я проверил, запустив сервер, а затем выполнил команду curl -v localhost:4221/mango и получил в ответ пустую строку. Разве не то же самое делает и тестер?

fraari 14.06.2024 10:38

Мой локон ничего не получил. Он просто бесконечно ждет ответа, в то время как ваш сервер бесконечно ждет закрытия соединения. Чего не произойдет. Я подозреваю, что ваш локон делает то же самое: вы неверно истолковываете то, что видите. Йой должен получить 404, а не пустую строку.

n. m. could be an AI 14.06.2024 10:58

Именно эту проблему я пытаюсь решить: почему Curl ничего не получает от сервера вместо: HTTP/1.1 404 Not Found\r\n\r\n, если запрос выглядит примерно так: $ curl -v localhost: 4221/abcdefg и HTTP/1.1 200 OK\r\n\r\n, когда запрос $curl -v localhost:4221. Но я не понимаю, что не так с кодом.

fraari 14.06.2024 11:02

«что не так с кодом» Ваш код ожидает закрытия соединения, чтобы начать обработку запроса. Вот что неправильно. Вы не знаете заранее, когда закончится запрос. Вам нужно искать метку конца запроса (\r\n\r\n) во время его чтения, каждый раз read возвращает положительное значение. Я напишу ответ по этому поводу.

n. m. could be an AI 14.06.2024 11:06

Тестирование вашего кода с помощью правильного запроса включает в себя запуск его в отладчике и просмотр того, где он чего-то ожидает. Если вы не обрабатываете запрос, потому что ждете чего-то другого, вы знаете, в чем дело.

Gerhardh 14.06.2024 11:51

«и я получил в ответ пустую строку» Как вы получили пустую строку? Чем это отличается от получения вообще ничего?

Gerhardh 14.06.2024 11:55

Простого HTTP-сервера не существует. Для реализации HTTP вам необходимо хорошее знание RFC 2616 и его преемников. Гораздо больше, чем здесь показано.

user207421 15.06.2024 02:11
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
10
73
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Основная ошибка в том, что ваш код ждет закрытия соединения и только потом начинает обработку запроса.

HTTP работает не так. Соединение все время остается открытым. Вам нужно найти маркер окончания запроса (\r\n\r\n), не дожидаясь закрытия соединения.

Это означает, что проверка на него каждый раз read возвращает положительное количество байтов.

Не забывайте, что read может вернуться в середине получения \r\n\r\n, поэтому, когда вы в следующий раз перезапустите поиск, read вернется, не проверяйте только новые байты.

Обратите внимание: технически \r\n\r\n — это конец заголовков, а не конец полного запроса (который может включать тело). Это упрощение для целей поставленной задачи.

Технически \r\n\r\n — это метка конца заголовка, а не метка конца запроса. Просто так случается, что запрос GET не имеет тела, но работоспособный сервер должен быть в состоянии обработать это.

Remy Lebeau 14.06.2024 20:10

@RemyLebeau правда, я добавляю примечание к ответу.

n. m. could be an AI 14.06.2024 22:00

Другие вопросы по теме