@abcbuzhiming 早期 jsp 引擎的实现和 php 是比较类似的，就是类似 *.jsp/* 都会被 jsp 引擎处理，只要路径中包含 jsp （并且文件存在），就会被映射
但是会存在歧义
比如 /1.jsp/2.jsp/3 并且这两个路径下的 jsp 文件都存在
那应该是映射为 servletPath=/1.jsp, pathInfo=/2.jsp/3 呢
还是 servletPath=/1.jsp/2.jsp, path=/3
完全依赖引擎的实现, Servlet 规范里面并没有这种定义的支持.

Servlet 规范的 mapping 只支持一个 *，即要么按文件名后缀 map （ pathInfo 永远是 null) 要么按前缀来 map, 而且必须是 ‘/*’ (/* 代表的就是 pathInfo)

默认的 jsp servlet mapping 的定义是写在 CATALINA_BASE/web.xml 里面, 就是 *.jsp, 通过这个 mapping 的请求也一定没有 path info

默认配置还有一个 DefaultServlet, 用来服务静态文件

至于 tomcat 的 jsp 引擎什么时候变更为和规范一致，我已经不记得了，只记得很早的时候是可以 (带 path) 的，后来就不可以了，也很可能是 tomcat 一直都默认不可以带 path 而是其它引擎（ resin / jetty 之类的) 可以
搜了一下也只能找到这个帖子 http://tomcat.10.x6.nabble.com/troubleshooting-getPathInfo-in-jsp-files-td2158648.html

最后，无论是哪个语言的 HTTP 服务引擎, 所面对的概念都没有什么太大差别, 基本上都遵循 CGI 的定义，你看 javadoc 的时候没看到 request.getXXX 的说明很多都有说明是相当于 CGI 的哪个环境变量吗？

@abcbuzhiming #7 我用得着去证明吗？是不是一回事你自己不会判断？就你这语气本来不想再回复了，算是知道什么叫做永远叫不醒一个自以为是的人。这是最后一条回复，你自己爱怎么理解就怎么理解吧

<servlet>
<servlet-name>c.jsp</servlet-name>
<jsp-file>/a/b/c.jsp</jsp-file>
</servlet>

<servlet-mapping>
<servlet-name>c.jsp</servlet-name>
<url-pattern>/a/b/c.jsp/*</url-pattern>
</servlet-mapping>

自己去看一下早期 jsp 引擎是怎么实现的
以及后来 jsp 的默认 mapping 怎么又被规范为了 *.jsp, 而规范不支持 *.jsp/* 这种类型的 mapping 只能通过手工加入

看看他们傲慢的态度吧

https://issuetracker.google.com/issues/36702869

Status
Won't Fix (Intended behavior)

有什么问题吗？
REQUEST_URI = /a/b/c.php/d/e/f?x=1
SCRIPT_NAME = /a/b/c.php
PATH_INFO = /d/e
_GET = [ “ x ” => 1 ]

是什么让你会觉得这是 java 发明的？

/t/343150

@mosliu 大部分的编码方式的编码空间都是不可还原的（意思是说 decode 为 string 后再 encode 无法保证得到原始的 byte 序列），包括我们最常见的 utf8 以及 gb18030，如果你希望可 100% 还原，那么可以选择 Files.readAllLines(Path, ISO_8859_1), 然后每行都要先使用 ISO_8859_1 重新 encode 回 bytes 再强制编码转换

猫还太小了吧，可能坠子太重了，

？语法糖的最佳使用场景













只不过 java 没有😏

unicode 输入法

你可以选择一天或几天 rebase 一次
rebase 有冲突的话，一般没必要保留自己的历史，可以选择改为 merge --no-commit，解决冲突后重新提交

HTML 怎么发音 YAML 就咋发音呗

你如果真想这么无聊的话
我给你个提供个方案
每次上传都触发一个 git commit，要不要 push 你自己想吧

jeklly 的 markdown 引擎以及参数是你可以自己配的

connector 和 catalina 是两个完全独立并且平行的模块
理论上 host 以及 app （ servlet context ）这一层是没有 ip 地址和端口概念的，和你在生命周期的哪一个阶段并无关联
所以你只能选择和容器实现完全捆绑的方法去实现，比如，通过 catalina.base property 找到 conf 目录位置，然后打开 server.xml 去解释 connector 的配置

源码是源码
数据是数据
runtime 是 runtime

是什么原因导致你会希望把这三者混淆不清的弄成一块的

tree object 可以用 git ls-tree | git mktree 重新计算出来
但如果用 git hash-object -t tree 的话，需要二进制格式，恐怕不是这么容易构造出来

commit object 的话，似乎没有什么好方法，好像也没有命令来构造二进制数据，虽然 git show <commit> — pretty=raw --no-patch 可以看到 commit 的完整内容，但没有命令可以把这个内容重新组装成一个 commit object