ims在nginx上的处理（无责任猜测）
最近得知CDN方面默认配置了reload-into-ims，而我们的html因为采用了ssi的include方式的原因，是没有last-modified的。在这种情况下的处理结果，让人好奇~
因为手头没测试机器，仅从我一知半解的nginx代码上推测一下：
1、之前博客里已经写过，nginx的ssi_module，在ngx_ssi_header_filter中简单的采用了ngx_http_clear_last_modified(r)抹去了last-modified的输出。
2、在nginx的module定义中，各filter的顺序如下：
ngx_module_t *ngx_modules[] = {
...............................................
&ngx_http_write_filter_module,
&ngx_http_header_filter_module,
&ngx_http_chunked_filter_module,
&ngx_http_range_header_filter_module,
&ngx_http_gzip_filter_module,
&ngx_http_postpone_filter_module,
&ngx_http_ssi_filter_module,
&ngx_http_charset_filter_module,
&ngx_http_userid_filter_module,
&ngx_http_headers_filter_module,
&ngx_http_copy_filter_module,
&ngx_http_range_body_filter_module,
&ngx_http_not_modified_filter_module,
NULL};
越后面的越先处理。也就是说，一个带有ims请求，会先经过not_modified_filter，然后才是ssi_filter。
而在ssi抹掉last-modified之前，文件是应该存在last-modified的。
nginx默认情况下，对一个ims请求的处理流程，参见淘宝核心系统部雕梁童鞋的博客《nginx中处理http header详解(1)》。大体上，是nginx获得这个请求文件的Mtime，存为变量last_modified_time；然后通过ngx_http_parse_time()换算IMS中的时间。如果ims!=last_modified_time，读取文件内容成response-body，否则clear掉content-length/content-type/content-encoding/accept-ranges等，进入下一步。
那么，如果一个html页本身没有修改，其中含有，而这个/ssi/test.html却变动了，那么在向这个html页发送ims的时候，就应该会是返回一个Not Modified，但在ssi_filter里又把last-modified也clear了……
3、在ssi_filter里如果要输出last-modified的话，如果单纯只是注释掉clear，并不起作用。不过在ngx_http_ssi_filter_module.c中，看到ngx_http_ssi_include()中调用了ngx_http_ssi_stub_output()这个handler，对virtual或file的拼接时处理header中的content-type如下：
if (!r->header_sent) {
r->headers_out.content_type_len =
r->parent->headers_out.content_type_len;
r->headers_out.content_type = r->parent->headers_out.content_type;
if (ngx_http_send_header(r) == NGX_ERROR) {
return NGX_ERROR;
}
}
return ngx_http_output_filter(r, out);
或许在这里加上
对r->parent->headers_out.last_modified_time和r->child->headers_out.last_modified_time的大小判断，然后赋值给r->headers_out.last_modified_time，然后把ssi_filter优先到not_modified_filter之前来？
C盲睡觉去也~~找时间写几个shtml测一下就知道自己对next_header_filter的理解对不对了~
