【web server】HTTP协议如何解析or封装

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 【web server】HTTP协议如何解析or封装

HTTP协议(关于HTTP协议之前的文章有写过)如何解析or封装?

首先来看下这块的处理过程,有一个整体的概念:

void Http::process() {
  //主线程读完数据后,来到这里处理
  HTTP_CODE read_ret = process_read();
  if (read_ret == NO_REQUEST) {
    //解析完数据发现客户端没有请求,直接退出
    return ;
  }
  //如果有请求,根据刚才解析的结果,封装报文
  bool write_ret = process_write(read_ret);
  if (!write_ret) {
    close_conn();
  }
  //告诉主线程,报文已经封装好了,可以发送了!
  modfd(s_iEpollfd, m_iSockFd, EPOLLOUT);
}

主线程读数据:

bool Http::read() {
  if (m_read_idx >= READ_BUFFER_SIZE) {
    return false;
  }
  int bytes_read = 0;
  while (true) {
    bytes_read = recv(m_iSockFd, m_read_buf + m_read_idx, READ_BUFFER_SIZE - m_read_idx, 0);
    if (bytes_read == -1) {
      if (errno == EAGAIN || errno == EWOULDBLOCK) {
        break;
      }
      return false;
    } else if (bytes_read == 0) {
      return false;
    }
    m_read_idx += bytes_read;
  }
  return true;
}

读到的正是这样一行一行的数据:

将数据循环读到m_read_buf中,接着开始处理读到的数据:

Http::HTTP_CODE Http::process_read() 
{
  ...
  while (...) {
    //拿到每一行数据
    text = get_line();
    switch (m_check_state) {
        case CHECK_STATE_REQUESTLINE: {
          //处理请求行
          parse_request_line(text);
          ...
          break;
        }
        case CHECK_STATE_HEADER: {
          //处理头部字段
          parse_headers(text);
          ...
          break;
        }
        default: {
          return INTERNAL_ERROR;
        }
    }
  }
}

用一个变量m_check_state来表示分析状态:

enum CHECK_STATE {
  CHECK_STATE_REQUESTLINE = 0, //当前正在分析请求行
  CHECK_STATE_HEADER  //当前正在分析头部字段
};

以便在parse_request_line之后改变状态,之后进入parse_headers中处理。

分析请求行和头部字段,可以了解到当前客户端要请求的资源的信息以及客户端一些信息。

若在解析的过程中发现客户端请求了页面,则在服务端找到该文件,并写入内存,等待发送,比如在do_request

Http::HTTP_CODE Http::do_request() {
  ...
  //若解析出的请求行中有“/”则默认返回index.html首页面
  if (strcmp(m_url, "/") == 0) {
    strcat(m_url, "index.html");
  }
  //处理其他,比如服务端没有资源,返回404.html 等等
  ...
  //若资源存在,读到内存中,等待发送
}

解析请求行和头部字段后,发现需要返回资源,便按照响应报文的格式封装报文并发送:

bool Http::process_write(HTTP_CODE ret) {
  switch (ret) {
    ...
    case NO_RESOURCE: {
      add_status_line(404, error_404_title);
      add_headers(strlen(error_404_form));
      add_content(error_404_form);
      break;
    }
    case FILE_REQUEST: {
      add_status_line(200, ok_200_title);
      add_headers(file.size());
      add_content(file);
      break;
    }
    default: {
      return false;
    }
  }
  return true;
}

add_status_line用来添加状态行,add_headers用来添加头部字段(之后添加一行空行),add_content用来添加内容。

至此,响应报文也就封装完成了,之后通知主线程发送报文即可。

相关文章
|
17天前
|
XML JSON API
ServiceStack:不仅仅是一个高性能Web API和微服务框架,更是一站式解决方案——深入解析其多协议支持及简便开发流程,带您体验前所未有的.NET开发效率革命
【10月更文挑战第9天】ServiceStack 是一个高性能的 Web API 和微服务框架,支持 JSON、XML、CSV 等多种数据格式。它简化了 .NET 应用的开发流程,提供了直观的 RESTful 服务构建方式。ServiceStack 支持高并发请求和复杂业务逻辑,安装简单,通过 NuGet 包管理器即可快速集成。示例代码展示了如何创建一个返回当前日期的简单服务,包括定义请求和响应 DTO、实现服务逻辑、配置路由和宿主。ServiceStack 还支持 WebSocket、SignalR 等实时通信协议,具备自动验证、自动过滤器等丰富功能,适合快速搭建高性能、可扩展的服务端应用。
75 3
|
25天前
|
缓存 移动开发 安全
Web安全-HTTP响应拆分(CRLF注入)漏洞
Web安全-HTTP响应拆分(CRLF注入)漏洞
63 1
|
26天前
|
运维 负载均衡 安全
深度解析:Python Web前后端分离架构中WebSocket的选型与实现策略
深度解析:Python Web前后端分离架构中WebSocket的选型与实现策略
78 0
|
6天前
|
弹性计算 安全 API
HTTP 405 Method Not Allowed:解析与解决
本文详细解析了HTTP 405 "Method Not Allowed" 错误,包括其定义、常见原因、示例代码及解决方案。通过检查API文档、修改请求方法或更新服务器配置,可有效解决此错误,提升Web开发效率。
41 2
|
15天前
|
前端开发 开发者 容器
构建响应式Web界面:Flexbox与Grid布局的深度解析
【10月更文挑战第11天】本文深入解析了CSS3中的Flexbox和Grid布局,探讨了它们的特点、应用场景及使用方法。Flexbox适用于一维布局,如导航栏;Grid布局则适用于二维布局,如复杂网格。通过示例代码和核心属性介绍,帮助开发者灵活构建响应式Web界面。
29 5
|
23天前
|
缓存 网络协议 前端开发
Web 性能优化|了解 HTTP 协议后才能理解的预加载
本文旨在探讨和分享多种预加载技术及其在提升网站性能、优化用户体验方面的应用。
|
13天前
|
缓存 前端开发 安全
前端开发者必备:HTTP状态码含义与用途解析,常见错误码产生原因及解决策略
前端开发者必备:HTTP状态码含义与用途解析,常见错误码产生原因及解决策略
66 0
|
26天前
http数据包抓包解析课程笔记
http数据包抓包解析课程笔记
|
26天前
|
JSON API 开发者
深入解析Python网络编程与Web开发:urllib、requests和http模块的功能、用法及在构建现代网络应用中的关键作用
深入解析Python网络编程与Web开发:urllib、requests和http模块的功能、用法及在构建现代网络应用中的关键作用
14 0
|
Web App开发 新零售 前端开发
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><head><meta http-equiv="Cont
1.尽可能地了解需求,系统层面适用开闭原则 2.模块化,低耦合,能快速响应变化,也可以避免一个子系统的问题波及整个大系统 3.
745 0

推荐镜像

更多