nginx的请求接收流程(二)

2023-05-16

在ngx_http_process_request_line函数中,解析完请求行之后,如果请求行的uri里面包含了域名部分,则将其保持在请求结构的headers_in成员的server字段,headers_in用来保存所有请求头,它的类型为ngx_http_headers_in_t:

typedef struct {
    ngx_list_t                        headers;

    ngx_table_elt_t                  *host;
    ngx_table_elt_t                  *connection;
    ngx_table_elt_t                  *if_modified_since;
    ngx_table_elt_t                  *if_unmodified_since;
    ngx_table_elt_t                  *user_agent;
    ngx_table_elt_t                  *referer;
    ngx_table_elt_t                  *content_length;
    ngx_table_elt_t                  *content_type;

    ngx_table_elt_t                  *range;
    ngx_table_elt_t                  *if_range;

    ngx_table_elt_t                  *transfer_encoding;
    ngx_table_elt_t                  *expect;

#if (NGX_HTTP_GZIP)
    ngx_table_elt_t                  *accept_encoding;
    ngx_table_elt_t                  *via;
#endif

    ngx_table_elt_t                  *authorization;

    ngx_table_elt_t                  *keep_alive;

#if (NGX_HTTP_PROXY || NGX_HTTP_REALIP || NGX_HTTP_GEO)
    ngx_table_elt_t                  *x_forwarded_for;
#endif

#if (NGX_HTTP_REALIP)
    ngx_table_elt_t                  *x_real_ip;
#endif

#if (NGX_HTTP_HEADERS)
    ngx_table_elt_t                  *accept;
    ngx_table_elt_t                  *accept_language;
#endif

#if (NGX_HTTP_DAV)
    ngx_table_elt_t                  *depth;
    ngx_table_elt_t                  *destination;
    ngx_table_elt_t                  *overwrite;
    ngx_table_elt_t                  *date;
#endif

    ngx_str_t                         user;
    ngx_str_t                         passwd;
    ngx_array_t                       cookies;

    ngx_str_t                         server;
    off_t                             content_length_n;
    time_t                            keep_alive_n;

    unsigned                          connection_type:2;
    unsigned                          msie:1;
    unsigned                          msie6:1;
    unsigned                          opera:1;
    unsigned                          gecko:1;
    unsigned                          chrome:1;
    unsigned                          safari:1;
    unsigned                          konqueror:1;
} ngx_http_headers_in_t;

接着,该函数会检查进来的请求是否使用的是http0.9,如果是的话则使用从请求行里得到的域名,调用ngx_http_find_virtual_server()函数来查找用来处理该请求的虚拟服务器配置,之前通过端口和地址找到的默认配置不再使用,找到相应的配置之后,则直接调用ngx_http_process_request()函数处理该请求,因为http0.9是最原始的http协议,它里面没有定义任何请求头,显然就不需要读取请求头的操作。

            if (r->host_start && r->host_end) {

                host = r->host_start;
                n = ngx_http_validate_host(r, &host,
                                           r->host_end - r->host_start, 0);

                if (n == 0) {
                    ngx_log_error(NGX_LOG_INFO, c->log, 0,
                                  "client sent invalid host in request line");
                    ngx_http_finalize_request(r, NGX_HTTP_BAD_REQUEST);
                    return;
                }

                if (n < 0) {
                    ngx_http_close_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);
                    return;
                }

                r->headers_in.server.len = n;
                r->headers_in.server.data = host;
            }

            if (r->http_version < NGX_HTTP_VERSION_10) {

                if (ngx_http_find_virtual_server(r, r->headers_in.server.data,
                                                 r->headers_in.server.len)
                    == NGX_ERROR)
                {
                    ngx_http_close_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);
                    return;
                }

                ngx_http_process_request(r);
                return;
            }

当然,如果是1.0或者更新的http协议,接下来要做的就是读取请求头了,首先nginx会为请求头分配空间,ngx_http_headers_in_t结构的headers字段为一个链表结构,它被用来保存所有请求头,初始为它分配了20个节点,每个节点的类型为ngx_table_elt_t,保存请求头的name/value值对,还可以看到ngx_http_headers_in_t结构有很多类型为ngx_table_elt_t*的指针成员,而且从它们的命名可以看出是一些常见的请求头名字,nginx对这些常用的请求头在ngx_http_headers_in_t结构里面保存了一份引用,后续需要使用的话,可以直接通过这些成员得到,另外也事先为cookie头分配了2个元素的数组空间,做完这些内存准备工作之后,该请求对应的读事件结构的处理函数被设置为ngx_http_process_request_headers,并随后马上调用了该函数。

            if (ngx_list_init(&r->headers_in.headers, r->pool, 20,
                              sizeof(ngx_table_elt_t))
                != NGX_OK)
            {
                ngx_http_close_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);
                return;
            }

            if (ngx_array_init(&r->headers_in.cookies, r->pool, 2,
                               sizeof(ngx_table_elt_t *))
                != NGX_OK)
            {
                ngx_http_close_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);
                return;
            }

            c->log->action = "reading client request headers";

            rev->handler = ngx_http_process_request_headers;
            ngx_http_process_request_headers(rev);
ngx_http_process_request_headers函数循环的读取所有的请求头,并保存和初始化和请求头相关的结构,下面详细分析一下该函数:
因为nginx对读取请求头有超时限制,ngx_http_process_request_headers函数作为读事件处理函数,一并处理了超时事件,如果读超时了,nginx直接给该请求返回408错误:
    if (rev->timedout) {
        ngx_log_error(NGX_LOG_INFO, c->log, NGX_ETIMEDOUT, "client timed out");
        c->timedout = 1;
        ngx_http_close_request(r, NGX_HTTP_REQUEST_TIME_OUT);
        return;
    }

读取和解析请求头的逻辑和处理请求行差不多,总的流程也是循环的调用ngx_http_read_request_header()函数读取数据,然后再调用一个解析函数来从读取的数据中解析请求头,直到解析完所有请求头,或者发生解析错误为主。当然由于涉及到网络io,这个流程可能发生在多个io事件的上下文中。

接着来细看该函数,先调用了ngx_http_read_request_header()函数读取数据,如果当前连接并没有数据过来,再直接返回,等待下一次读事件到来,如果读到了一些数据则调用ngx_http_parse_header_line()函数来解析,同样的该解析函数实现为一个有限状态机,逻辑很简单,只是根据http协议的解析一个请求头的name/vale对,每次调用该函数最多解析出一个请求头,该函数返回4种不同返回值,表示不同解析结果:

1,返回NGX_OK,表示解析出了一行请求头,这时还要判断解析出的请求头名字里面是否有非法字符,名字里面合法的字符包括字母,数字和连字符(-),另外如果设置了underscores_in_headers指令为on,则下划线也是合法字符,但是nginx默认下划线不合法,当请求头里面包含了非法的字符,nginx默认只是忽略这一行请求头;如果一切都正常,nginx会将该请求头及请求头名字的hash值保存在请求结构体的headers_in成员的headers链表,而且对于一些常见的请求头,如Host,Connection,nginx采用了类似于配置指令的方式,事先给这些请求头分配了一个处理函数,当解析出一个请求头时,会检查该请求头是否有设置处理函数,有的话则调用之,nginx所有有处理函数的请求头都记录在ngx_http_headers_in全局数组中:
typedef struct {
    ngx_str_t                         name;
    ngx_uint_t                        offset;
    ngx_http_header_handler_pt        handler;
} ngx_http_header_t;

ngx_http_header_t  ngx_http_headers_in[] = {
    { ngx_string("Host"), offsetof(ngx_http_headers_in_t, host),
                 ngx_http_process_host },

    { ngx_string("Connection"), offsetof(ngx_http_headers_in_t, connection),
                 ngx_http_process_connection },

    { ngx_string("If-Modified-Since"),
                 offsetof(ngx_http_headers_in_t, if_modified_since),
                 ngx_http_process_unique_header_line },

    { ngx_string("If-Unmodified-Since"),
                 offsetof(ngx_http_headers_in_t, if_unmodified_since),
                 ngx_http_process_unique_header_line },

    { ngx_string("User-Agent"), offsetof(ngx_http_headers_in_t, user_agent),
                 ngx_http_process_user_agent },


    { ngx_string("Referer"), offsetof(ngx_http_headers_in_t, referer),
                 ngx_http_process_header_line },

    { ngx_string("Content-Length"),
                 offsetof(ngx_http_headers_in_t, content_length),
                 ngx_http_process_unique_header_line },

    { ngx_string("Content-Type"),
                 offsetof(ngx_http_headers_in_t, content_type),
                 ngx_http_process_header_line },

    { ngx_string("Range"), offsetof(ngx_http_headers_in_t, range),
                 ngx_http_process_header_line },

    { ngx_string("If-Range"),
                 offsetof(ngx_http_headers_in_t, if_range),
                 ngx_http_process_unique_header_line },

    { ngx_string("Transfer-Encoding"),
                 offsetof(ngx_http_headers_in_t, transfer_encoding),
                 ngx_http_process_header_line },

    { ngx_string("Expect"),
                 offsetof(ngx_http_headers_in_t, expect),
                 ngx_http_process_unique_header_line },

#if (NGX_HTTP_GZIP)
    { ngx_string("Accept-Encoding"),
                 offsetof(ngx_http_headers_in_t, accept_encoding),
                 ngx_http_process_header_line },

    { ngx_string("Via"), offsetof(ngx_http_headers_in_t, via),
                 ngx_http_process_header_line },
#endif

    { ngx_string("Authorization"),
                 offsetof(ngx_http_headers_in_t, authorization),
                 ngx_http_process_unique_header_line },

    { ngx_string("Keep-Alive"), offsetof(ngx_http_headers_in_t, keep_alive),
                 ngx_http_process_header_line },


#if (NGX_HTTP_PROXY || NGX_HTTP_REALIP || NGX_HTTP_GEO)
    { ngx_string("X-Forwarded-For"),
                 offsetof(ngx_http_headers_in_t, x_forwarded_for),
                 ngx_http_process_header_line },
#endif

#if (NGX_HTTP_REALIP)
    { ngx_string("X-Real-IP"),
                 offsetof(ngx_http_headers_in_t, x_real_ip),
                 ngx_http_process_header_line },
#endif

#if (NGX_HTTP_HEADERS)
    { ngx_string("Accept"), offsetof(ngx_http_headers_in_t, accept),
                 ngx_http_process_header_line },

    { ngx_string("Accept-Language"),
                 offsetof(ngx_http_headers_in_t, accept_language),
                 ngx_http_process_header_line },
#endif

#if (NGX_HTTP_DAV)
    { ngx_string("Depth"), offsetof(ngx_http_headers_in_t, depth),
                 ngx_http_process_header_line },

    { ngx_string("Destination"), offsetof(ngx_http_headers_in_t, destination),
                 ngx_http_process_header_line },

    { ngx_string("Overwrite"), offsetof(ngx_http_headers_in_t, overwrite),
                 ngx_http_process_header_line },

    { ngx_string("Date"), offsetof(ngx_http_headers_in_t, date),
                 ngx_http_process_header_line },
#endif

    { ngx_string("Cookie"), 0, ngx_http_process_cookie },

    { ngx_null_string, 0, NULL }
};

ngx_http_headers_in数组当前包含了25个常用的请求头,每个请求头都设置了一个处理函数,当前其中一部分请求头设置的是公共的处理函数,这里有2个公共的处理函数,ngx_http_process_header_line和ngx_http_process_unique_header_line。

先来看一下处理函数的函数指针定义:
typedef ngx_int_t (*ngx_http_header_handler_pt)(ngx_http_request_t *r,
    ngx_table_elt_t *h, ngx_uint_t offset);
它有3个参数,r为对应的请求结构,h为该请求头在headers_in.headers链表节点的指针,offset为该请求头的引用在ngx_http_headers_in_t结构中的偏移。
再来看ngx_http_process_header_line函数:

static ngx_int_t
ngx_http_process_header_line(ngx_http_request_t *r, ngx_table_elt_t *h,
    ngx_uint_t offset)
{
    ngx_table_elt_t  **ph;

    ph = (ngx_table_elt_t **) ((char *) &r->headers_in + offset);

    if (*ph == NULL) {
        *ph = h;
    }

    return NGX_OK;
}

这个函数只是简单将该请求头在ngx_http_headers_in_t结构中保存一份引用。ngx_http_process_unique_header_line功能类似,不同点在于该函数会检查这个请求头是否是重复的,如果是的话,则给该请求返回400错误。

ngx_http_headers_in数组中剩下的请求头都有自己特殊的处理函数,这些特殊的函数根据对应的请求头有一些特殊的处理,下面我们拿Host头的处理函数ngx_http_process_host做一下介绍:
static ngx_int_t
ngx_http_process_host(ngx_http_request_t *r, ngx_table_elt_t *h,
    ngx_uint_t offset)
{
    u_char   *host;
    ssize_t   len;

    if (r->headers_in.host == NULL) {
        r->headers_in.host = h;
    }

    host = h->value.data;
    len = ngx_http_validate_host(r, &host, h->value.len, 0);

    if (len == 0) {
        ngx_log_error(NGX_LOG_INFO, r->connection->log, 0,
                      "client sent invalid host header");
        ngx_http_finalize_request(r, NGX_HTTP_BAD_REQUEST);
        return NGX_ERROR;
    }

    if (len < 0) {
        ngx_http_close_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);
        return NGX_ERROR;
    }

    if (r->headers_in.server.len) {
        return NGX_OK;
    }

    r->headers_in.server.len = len;
    r->headers_in.server.data = host;

    return NGX_OK;
}
此函数的目的也是保存Host头的快速引用,它会对Host头的值做一些合法性检查,并从中解析出域名,保存在headers_in.server字段,实际上前面在解析请求行时,headers_in.server可能已经被赋值为从请求行中解析出来的域名,根据http协议的规范,如果请求行中的uri带有域名的话,则域名以它为准,所以这里需检查一下headers_in.server是否为空,如果不为空则不需要再赋值。

其他请求头的特殊处理函数,不再做介绍,大致都是根据该请求头在http协议中规定的意义及其值设置请求的一些属性,必备后续使用。

对一个合法的请求头的处理大致为如上所述;

2,返回NGX_AGAIN,表示当前接收到的数据不够,一行请求头还未结束,需要继续下一轮循环。在下一轮循环中,nginx首先检查请求头缓冲区header_in是否已满,如够满了,则调用ngx_http_alloc_large_header_buffer()函数分配更多缓冲区,下面分析一下ngx_http_alloc_large_header_buffer函数:
static ngx_int_t
ngx_http_alloc_large_header_buffer(ngx_http_request_t *r,
    ngx_uint_t request_line)
{
    u_char                    *old, *new;
    ngx_buf_t                 *b;
    ngx_http_connection_t     *hc;
    ngx_http_core_srv_conf_t  *cscf;

    ngx_log_debug0(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
                   "http alloc large header buffer");

    /*
     * 在解析请求行阶段,如果客户端在发送请求行之前发送了大量回车换行符将
     * 缓冲区塞满了,针对这种情况,nginx只是简单的重置缓冲区,丢弃这些垃圾
     * 数据,不需要分配更大的内存。
     */
    if (request_line && r->state == 0) {

        /* the client fills up the buffer with "\r\n" */

        r->request_length += r->header_in->end - r->header_in->start;

        r->header_in->pos = r->header_in->start;
        r->header_in->last = r->header_in->start;

        return NGX_OK;
    }

    /* 保存请求行或者请求头在旧缓冲区中的起始地址 */
    old = request_line ? r->request_start : r->header_name_start;

    cscf = ngx_http_get_module_srv_conf(r, ngx_http_core_module);

    /* 如果一个大缓冲区还装不下请求行或者一个请求头,则返回错误 */
    if (r->state != 0
        && (size_t) (r->header_in->pos - old)
                                     >= cscf->large_client_header_buffers.size)
    {
        return NGX_DECLINED;
    }

    hc = r->http_connection;

    /* 首先在ngx_http_connection_t结构中查找是否有空闲缓冲区,有的话,直接取之 */
    if (hc->nfree) {
        b = hc->free[--hc->nfree];

        ngx_log_debug2(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
                       "http large header free: %p %uz",
                       b->pos, b->end - b->last);

    /* 检查给该请求分配的请求头缓冲区个数是否已经超过限制,默认最大个数为4个 */
    } else if (hc->nbusy < cscf->large_client_header_buffers.num) {

        if (hc->busy == NULL) {
            hc->busy = ngx_palloc(r->connection->pool,
                  cscf->large_client_header_buffers.num * sizeof(ngx_buf_t *));
            if (hc->busy == NULL) {
                return NGX_ERROR;
            }
        }

        /* 如果还没有达到最大分配数量,则分配一个新的大缓冲区 */
        b = ngx_create_temp_buf(r->connection->pool,
                                cscf->large_client_header_buffers.size);
        if (b == NULL) {
            return NGX_ERROR;
        }

        ngx_log_debug2(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
                       "http large header alloc: %p %uz",
                       b->pos, b->end - b->last);

    } else {
        /* 如果已经达到最大的分配限制,则返回错误 */
        return NGX_DECLINED;
    }

    /* 将从空闲队列取得的或者新分配的缓冲区加入已使用队列 */
    hc->busy[hc->nbusy++] = b;

    /*
     * 因为nginx中,所有的请求头的保存形式都是指针(起始和结束地址),
     * 所以一行完整的请求头必须放在连续的内存块中。如果旧的缓冲区不能
     * 再放下整行请求头,则分配新缓冲区,并从旧缓冲区拷贝已经读取的部分请求头,
     * 拷贝完之后,需要修改所有相关指针指向到新缓冲区。
     * status为0表示解析完一行请求头之后,缓冲区正好被用完,这种情况不需要拷贝
     */
    if (r->state == 0) {
        /*
         * r->state == 0 means that a header line was parsed successfully
         * and we do not need to copy incomplete header line and
         * to relocate the parser header pointers
         */

        r->request_length += r->header_in->end - r->header_in->start;

        r->header_in = b;

        return NGX_OK;
    }

    ngx_log_debug1(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
                   "http large header copy: %d", r->header_in->pos - old);

    r->request_length += old - r->header_in->start;

    new = b->start;

    /* 拷贝旧缓冲区中不完整的请求头 */
    ngx_memcpy(new, old, r->header_in->pos - old);

    b->pos = new + (r->header_in->pos - old);
    b->last = new + (r->header_in->pos - old);

    /* 修改相应的指针指向新缓冲区 */
    if (request_line) {
        r->request_start = new;

        if (r->request_end) {
            r->request_end = new + (r->request_end - old);
        }

        r->method_end = new + (r->method_end - old);

        r->uri_start = new + (r->uri_start - old);
        r->uri_end = new + (r->uri_end - old);

        if (r->schema_start) {
            r->schema_start = new + (r->schema_start - old);
            r->schema_end = new + (r->schema_end - old);
        }

        if (r->host_start) {
            r->host_start = new + (r->host_start - old);
            if (r->host_end) {
                r->host_end = new + (r->host_end - old);
            }
        }

        if (r->port_start) {
            r->port_start = new + (r->port_start - old);
            r->port_end = new + (r->port_end - old);
        }

        if (r->uri_ext) {
            r->uri_ext = new + (r->uri_ext - old);
        }

        if (r->args_start) {
            r->args_start = new + (r->args_start - old);
        }

        if (r->http_protocol.data) {
            r->http_protocol.data = new + (r->http_protocol.data - old);
        }

    } else {
        r->header_name_start = new;
        r->header_name_end = new + (r->header_name_end - old);
        r->header_start = new + (r->header_start - old);
        r->header_end = new + (r->header_end - old);
    }

    r->header_in = b;

    return NGX_OK;
}

当ngx_http_alloc_large_header_buffer函数返回NGX_DECLINED)时,表示客户端发送了过大的一行请求头,或者是整个请求头部超过了限制,nginx会返回494错误,注意到nginx再返回494错误之前将请求的lingering_close标识置为了1,这样做的目的是在返回响应之丢弃掉客户端发过来的其他数据;

3,返回NGX_HTTP_PARSE_INVALID_HEADER,表示请求头解析过程中遇到错误,一般为客户端发送了不符合协议规范的头部,此时nginx返回400错误。

4,返回NGX_HTTP_PARSE_HEADER_DONE,表示所有请求头已经成功的解析,这时请求的状态被设置为NGX_HTTP_PROCESS_REQUEST_STATE,意味着结束了请求读取阶段,正式进入了请求处理阶段,但是实际上请求可能含有请求体,nginx在请求读取阶段并不会去读取请求体,这个工作交给了后续的请求处理阶段的模块,这样做的目的是nginx本身并不知道这些请求体是否有用,如果后续模块并不需要的话,一方面请求体一般较大,如果全部读取进内存,则白白耗费大量的内存空间,另一方面即使nginx将请求体写进磁盘,但是涉及到磁盘io,会耗费比较多时间。所以交由后续模块来决定读取还是丢弃请求体是最明智的办法。

读取完请求头之后,nginx调用了ngx_http_process_request_header()函数,这个函数主要做了两个方面的事情,一是调用ngx_http_find_virtual_server()函数查找虚拟服务器配置;二是对一些请求头做一些协议的检查。比如对那些使用http1.1协议但是却没有发送Host头的请求,nginx给这些请求返回400错误。还有nginx现在的版本并不支持chunked格式的输入,如果某些请求申明自己使用了chunked格式的输入(请求带有值为chunked的transfer_encoding头部),nginx给这些请求返回411错误。等等。
最后调用ngx_http_process_request()函数处理请求;
至此,nginx接收请求接收流程就介绍完毕。


本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

nginx的请求接收流程(二) 的相关文章

  • Nginx 对 cms 后端的重写规则

    我需要在 nginx 服务器中制定 url 重写规则 服务器块 就像我之前的 apache 服务器一样 这是 htaccess 中的代码 我需要将其实现 转换 到我现有的代码中 RewriteRule A Za z0 9 A Za z0 9
  • 使用 nginx 代理时在 RStudio 中运行闪亮的应用程序

    我正在尝试使用通过 nginx 代理的 RStudio 服务器来开发一个闪亮的应用程序 当我使用 RStudio 而不是服务器 来运行闪亮的应用程序时 一切正常 但是 当我通过代理 RStudio 运行时 该应用程序出现在 查看器 窗格中
  • 站点启用/中不允许使用 nginx“mail”和“stream”指令

    当我尝试在 nginx 中使用流或邮件指令时遇到问题 我正在使用 nginx 1 16 1 和 Ubuntu 18 04 4 LTS 这是我的 nginx conf user www data worker processes auto p
  • 为什么 Nginx 以相反的顺序提供客户端 SSL DN?

    我很好奇为什么某些 Web 服务器 例如 Nginx 以相反的顺序提供客户端 SSL DN Web 应用程序将 DN 发布到 Java Web 服务 该服务尝试创建 Javajavax naming ldap LdapName http d
  • 从 Nginx 到 Express.js 上的 socket.io 的反向代理上“无法获取”

    我已经关注了通过私有网络让 Node js 在两台 Ubuntu 14 04 服务器上通过 Nginx 工作 Node js 位于 myappserver 上 通过私有 IP myprivatewebserver 访问 并通过 mypubl
  • 如何在 Docker 容器中运行 Nginx 而不停止?

    我在 Docker 容器上安装了 Nginx 并尝试像这样运行它 docker run i t p 80 80 mydockerimage usr sbin nginx 问题是 Nginx 的工作方式是 初始进程立即生成一个 Nginx 主
  • 命名 Docker 卷以共享构建而不更新

    我工作的公司的开发人员要求我用 Docker 做一些不同的事情 然后我也被使用了 目标是拥有 2 个具有以下职责的容器 容器A 节点容器将构建前端 React 应用程序并将捆绑包放入名为的目录中app dist 完成后 容器将停止运行 容器
  • 使用 client_body_in_file_only 进行 nginx 文件上传

    晚上好 我需要将静态内容上传到 nginx 服务器 1 9 因此上传模块不适用于此版本 我读过这篇文章 Nginx 直接文件上传 无需通过后端传递 https coderwall com p swgfvw nginx direct file
  • 通过 nginx 入口控制器进行基本身份验证

    我正在使用 nginx 入口控制器 https kubernetes github io ingress nginx deploy https kubernetes github io ingress nginx deploy 在 AWS
  • Kong - 验证上游 ssl(ssl_proxy 打开)

    我已经成功为 API 安装了 kong 网关 该 API 通过上游负载平衡到多个目标 应用程序服务器 现在 我有一个我的应用程序服务器的自签名证书 kong 和目标之间的 ssl 握手应该失败 我推断 kong 不验证上游证书 经过一些研究
  • 如何将亚马逊颁发的免费证书配置到nginx.config

    我已经安装了nginx服务器在Amazon Linux 2环境 在创建弹性负载均衡器期间 我创建了 Amazon 的免费证书 现在 我想通过以下方式访问我的服务器https port 443 我该如何配置这个SSL证书在nginx conf
  • nginx - 记录 SSL 握手失败

    我正在运行启用了 SSL 的 nginx 服务器 我的协议 密码设置相当安全 我已经在 ssllabs com 上检查过它们 但是 因为这是一个由我无法控制的 http 客户端调用的 Web 服务 所以我担心兼容性 重点是 有没有办法在我的
  • 如果我在不打算升级到 websocket 连接的 HTTP 请求中包含“Upgrade”和“Connection”标头,会发生什么情况?

    我有一个 Nginx 服务器块 用于代理对 node js 服务器的请求 该服务器同时提供 HTTP 内容和 WS websocket 内容 是否可以在不应升级到 Websocket 连接的请求上添加升级标头 即使用 Nginx 代理到服务
  • nginx 匹配位置中的特定单词

    我在匹配 nginx request body 变量中的特定单词时遇到问题 如果正文请求中有特殊单词 我想代理传递 所以我的方法是这样的 location php if request body proxy pass http test p
  • nginx代理认证拦截

    我有几个服务 它们支持 nginx 实例 为了处理身份验证 在 nginx 中 我拦截每个请求并将其发送到身份验证服务 在那里 如果凭据正确 我将设置一个包含用户相关信息的 cookie 现在 请求应该被路由到适当的服务 并设置 cooki
  • NGINX 上的 SSL 终止

    我已经购买了 SSL 证书 并在验证模数时正确地将其捆绑在一起 即https kb wisc edu middleware 4064 https kb wisc edu middleware 4064 那么哈希值是相同的 我已将证书和密钥移
  • Nginx merge_slashes 重定向

    我在我的 Java 应用程序中使用 nginx 我的问题是 nginx 正在合并斜杠 我无法将我的网站重定向到正确的版本 例如 http goout cz cs koncerty praha 被合并到 http goout cz cs ko
  • 在 docker 中将 pgadmin 连接到 postgres

    我有一个docker compose与服务文件python nginx postgres and pgadmin services postgres image postgres 9 6 env file env volumes postg
  • 错误请求 400:nginx/gunicorn

    我已经遵循了这个教程 http blog wercker com 2013 11 25 django 16 part3 html http blog wercker com 2013 11 25 django 16 part3 html我现
  • 阻止 ingress-nginx 负载均衡器上的特定路径

    我有许多指向入口控制器 IP 的域 我想阻止所有域 站点的 特定路径 有没有办法做到这一点 我可以用nginx ingress kubernetes io configuration snippet 对于每个站点 但正在寻找同时处理所有站点

随机推荐

  • Flask【第十章】:特殊装饰器 @app.before_request 和 @app.after_request 以及@app.errorhandler...

    特殊装饰器 64 app before request 和 64 app after request以及 64 app errorhandler 一 背景 xff1a Flask我们已经学习很多基础知识了 现在有一个问题 我们现在有一个 F
  • Linux Socket基础介绍

    Linux Socket函数库是从Berkeley大学开发的BSD UNIX系统中移植过来的 BSD Socket接口是众多Unix系统中被广泛支持的TCP IP通信接口 xff0c Linux下的Socket程序设计 xff0c 除了微小
  • libcurl库的使用(通过libcurl库下载url图像)

    1 从http curl haxx se download html下载libcurl源码 xff0c 解压缩 xff1b 2 通过CMake cmake gui 生成vs2013 x64位 CURL sln xff1b 3 打开CURL
  • 人工神经网络简介

    本文主要对人工神经网络基础进行了描述 xff0c 主要包括人工神经网络的概念 发展 特点 结构 模型 本文是个科普文 xff0c 来自网络资料的整理 一 人工神经网络的概念 人工神经网络 xff08 Artificial Neural Ne
  • 卷积神经网络(CNN)基础介绍

    本文是对卷积神经网络的基础进行介绍 xff0c 主要内容包括卷积神经网络概念 卷积神经网络结构 卷积神经网络求解 卷积神经网络LeNet 5结构分析 卷积神经网络注意事项 一 卷积神经网络概念 上世纪60年代 xff0c Hubel等人通过
  • C++中struct的使用

    C 43 43 语言继承了C语言的struct xff0c 并且加以扩充 在C语言中struct是只能定义数据成员 xff0c 而不能定义成员函数的 而在C 43 43 中 xff0c struct类似于class xff0c 在其中既可以
  • Windows与Linux之间互传文件的方法

    以下方法均是以Windows为操作机 xff1a 1 通过WinSCP WinSCP是一款开源的SFTP客户端 xff0c 运行于Windows系统下 xff0c 遵照GPL发布 WinSCP除了SFTP xff0c 还支持SSH SCP
  • 非对称加密算法RSA公钥私钥的模数和指数提取方法

    生成非对称加密算法RSA公钥 私钥的方法 xff1a 1 通过OpenSSL库生成 xff0c 可参考 https github com fengbingchun OpenSSL Test blob master demo OpenSSL
  • Base64简介

    Base64是一种基于64个可打印字符来表示二进制数据的表示方法 由于2 6 61 64 xff0c 所以每6个比特为一个单元 xff0c 对应某个可打印字符 3个字节有24个比特 xff0c 对应于4个Base64单元 xff0c 即3个
  • HTTP协议简介

    HTTP HyperText Transfer Protocol 超文本传输协议 xff1a 是一种用于分布式 协作式和超媒体信息系统的应用层协议 HTTP是万维网的数据通信的基础 设计HTTP最初的目的是为了提供一种发布和接收HTML页面
  • HTTPS协议简介

    HTTPS HyperText Transfer Protocol Secure 超文本传输安全协议 xff1a 是一种透过计算机网络进行安全通信的传输协议 HTTPS经由HTTP进行通信 xff0c 但利用SSL TLS来加密数据包 HT
  • base64开源库介绍及使用

    网上有一些开源的base64编解码库的实现 xff0c 下面介绍几个 xff1a cppcodec是一个仅包括头文件的C 43 43 11库 xff0c 用于编解码RFC 4648中指定的base64 base64url base32 ba
  • Ubuntu下使用CMake编译OpenSSL源码操作步骤(C语言)

    OpenSSL的版本为1 0 1g xff0c 在ubuntu下通过CMake仅编译c代码不包括汇编代码 xff0c 脚本内容如下 xff1a build sh内容 xff1a bin bash real path 61 realpath
  • ImageNet图像数据集介绍

    ImageNet图像数据集始于2009年 xff0c 当时李飞飞教授等在CVPR2009上发表了一篇名为 ImageNet A Large Scale Hierarchical Image Database 的论文 xff0c 之后就是基于
  • 网络文件系统(NFS)简介

    网络文件系统 Network File System NFS 是一种分布式文件系统协议 xff0c 最初由Sun Microsystems公司开发 xff0c 并于1984年发布 其功能旨在允许客户端主机可以像访问本地存储一样通过网络访问服
  • 实时流协议(RTSP)简介

    RTSP Real Time Streaming Protocol xff0c RFC2326 xff0c 实时流传输协议 xff0c 是TCP IP协议体系中的一个应用层协议 xff0c 由哥伦比亚大学 网景 Netscape 和Real
  • 远程过程调用RPC简介

    RPC Remote Procedure Call 远程过程调用 xff1a 是一种通过网络从远程计算机程序上请求服务 xff0c 而不需要了解底层网络技术的思想 RPC是一种技术思想而非一种规范或协议 xff0c 常见RPC技术和框架有
  • C语言中头文件包含的处理原则

    很多事不深入以为自己懂了 xff0c 但真正用到项目上 xff0c 才发现了问题 曾以为自己写C语言已经轻车熟路了 xff0c 特别是对软件文件的工程管理上 xff0c 因为心里对自己的代码编写风格还是有自信的 毕竟刚毕业时老大对我最初的训
  • Unity3D物体自动躲避障碍物

    Unity版本 2017 4 4f1 基本思路 物体向前发射一个射线 xff0c 检测到碰撞后 xff0c 根据碰撞信息选择新的方向 最终结果如下 具体实现步骤代码 1 物体添加胶囊体碰撞组件CapsuleCollider 通过发射虚拟胶囊
  • nginx的请求接收流程(二)

    在ngx http process request line函数中 xff0c 解析完请求行之后 xff0c 如果请求行的uri里面包含了域名部分 xff0c 则将其保持在请求结构的headers in成员的server字段 xff0c h