Web | W10N

context-param&init-param

‘context-param&init-param’ 的作用: web.xml的配置中配置作用 1. 启动一个WEB项目的时候,容器(如:Tomcat)会去读它的配置文件web.xml.读两个节点: 和 2.紧接着,容器创建一个ServletContext(上下文),这个WEB项目所有部分都将共享这个上下文. 3.容器将转化为键值对,并交给ServletContext. 4.容器创建中的类实例,即创建监听. 5.在监听中会有contextInitialized(ServletContextEvent args)初始化方法,在这个方法中获得ServletContext = ServletContextEvent.getServletContext(); context-param的值 = ServletContext.getInitParameter(“context-param的键”); 6.得到这个context-param的值之后,你就可以做一些操作了.注意,这个时候你的WEB项目还没有完全启动完成.这个动作会比所有的Servlet都要早. 换句话说,这个时候,你对中的键值做的操作,将在你的WEB项目完全启动之前被执行. 7.举例.你可能想在项目启动之前就打开数据库. 那么这里就可以在中设置数据库的连接方式,在监听类中初始化数据库的连接. 8.这个监听是自己写的一个类,除了初始化方法,它还有销毁方法.用于关闭应用前释放资源.比如说数据库连接的关闭. web.xml里面可以定义两种参数: (1)application范围内的参数，存放在servletcontext中，在web.xml中配置如下: <context-param> <param-name>context/param</param-name> <param-value>avalible during application</param-value> </context-param> <context-param> <param-name>cpn</param-name> <param-value>cpv</param-value> </context-param> (2)servlet范围内的参数，只能在servlet的init()方法中取得，在web.xml中配置如下: ...

servlet3.0

servlet3.0 http://www.ibm.com/developerworks/cn/java/j-lo-servlet30/ Servlet 3.0 作为 Java EE 6 规范体系中一员，随着 Java EE 6 规范一起发布。该版本在前一版本 (Servlet 2.5) 的基础上提供了若干新特性用于简化 Web 应用的开发和部署。其中有几项特性的引入让开发者感到非常兴奋，同时也获得了 Java 社区的一片赞誉之声: 异步处理支持: 有了该特性，Servlet 线程不再需要一直阻塞，直到业务处理完毕才能再输出响应，最后才结束该 Servlet 线程。在接收到请求之后，Servlet 线程可以将耗时的操作委派给另一个线程来完成，自己在不生成响应的情况下返回至容器。针对业务处理较耗时的情况，这将大大减少服务器资源的占用，并且提高并发处理速度。新增的注解支持: 该版本新增了若干注解，用于简化 Servlet、过滤器 (Filter) 和监听器 (Listener) 的声明，这使得 web.xml 部署描述文件从该版本开始不再是必选的了。可插性支持: 熟悉 Struts2 的开发者一定会对其通过插件的方式与包括 Spring 在内的各种常用框架的整合特性记忆犹新。将相应的插件封装成 JAR 包并放在类路径下，Struts2 运行时便能自动加载这些插件。现在 Servlet 3.0 提供了类似的特性，开发者可以通过插件的方式很方便的扩充已有 Web 应用的功能，而不需要修改原有的应用。新增的注解支持 Servlet 3.0 的部署描述文件 web.xml 的顶层标签有一个 metadata-complete 属性，该属性指定当前的部署描述文件是否是完全的。如果设置为 true，则容器在部署时将只依赖部署描述文件，忽略所有的注解 (同时也会跳过 web-fragment.xml 的扫描，亦即禁用可插性支持，具体请看后文关于可插性支持的讲解) ；如果不配置该属性，或者将其设置为 false，则表示启用注解支持 (和可插性支持) 。 ...

XHR与fetch

XHR与fetch XMLHttpRequest 是一个内建的浏览器对象，它允许使用 JavaScript 发送 HTTP 请求。虽然它的名字里面有 “XML” 一词，但它可以操作任何数据，而不仅仅是 XML 格式。我们可以用它来上传/下载文件，跟踪进度等。现如今，我们有一个更为现代的方法叫做 fetch，它的出现使得 XMLHttpRequest 在某种程度上被弃用。在现代 Web 开发中，出于以下三种原因，我们还在使用 XMLHttpRequest：历史原因：我们需要支持现有的使用了 XMLHttpRequest 的脚本。我们需要兼容旧浏览器，并且不想用 polyfill (例如为了使脚本更小）。我们需要做一些 fetch 目前无法做到的事情，例如跟踪上传进度。 https://zh.javascript.info/xmlhttprequest <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>title0</title> <!–css–>  <script type="text/javascript"> window.onload = function () { console.log('window.onload') } function func0(){ // 1. Create a new XMLHttpRequest object let xhr = new XMLHttpRequest(); // 2. Configure it: GET-request for the URL /article/.../load xhr.open('GET', 'http://localhost:8000'); // 3. Send the request over the network xhr.send(); // 4. This will be called after the response is received xhr.onload = function () { if (xhr.status !== 200) { // analyze HTTP status of the response console.log(`Error ${xhr.status}: ${xhr.statusText}`); // e.g. 404: Not Found } else { // show the result console.log(`Done, got ${xhr.response.length} bytes`); // response is the server } xhr.onprogress = function (event) { if (event.lengthComputable) { console.log(`Received ${event.loaded} of ${event.total} bytes`); } else { console.log(`Received ${event.loaded} bytes`); // no Content-Length } }; xhr.onerror = function () { console.log("Request failed"); }; } } function func1(){ fetch('http://localhost:8000').then(function(response) { console.log('response') console.log(response.json()); return response.json(); }).then(function(data) { console.log('data') console.log(data); }).catch(function() { console.log("Booo"); }); } </script> </head> <body> body0 <button type="button" onclick="func0()">button0</button> <button type="button" onclick="func1()">button1</button> </body> </html>

template for web.xml Servlet3.0

template for web.xml Servlet3.0 <?xml version="1.0" encoding="UTF-8"?> <web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"> </web-app> http://dominikdorn.com/2010/03/web-xml-web-fragment-xml-2-3-2-4-2-5-3-0/

welcome-file-list

welcome-file-list 当用户在浏览器中输入的URL不包含某个servlet名或JSP页面时，welcome-file-list元素可指定显示的默认文件。 <!ELEMENT welcome-file-list (welcome-file+)> <!ELEMENT welcome-file (#PCDATA)> 举个例子说明，假设用户在浏览器的地址框中输入http://www.mycompany.com/appName/等地址。如果在Web应用的部署描述符中指定welcome-file-list元素，用户就会看到一个权限错误消息，或者是应用目录下的文件和目录列表。如果定义了welcome-file-list元素，用户就能看到由该元素指定的具体文件。 welcome-file子元素用于指定默认文件的名称。welcome-file-list元素可以包含一个或多个welcome-file子元素。如果在第一个welcome-file元素中没有找到指定的文件，Web容器就会尝试显示第二个，以此类推。下面是一个包含welcome-file-list元素的部署描述符。该元素包含两个welcome-file元素: 第一个指定应用目录中的main.html文件，第二个定义jsp目录下的welcom.jsp文件，jsp目录也在应用目录下。 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <welcome-file-list> <welcome-file>main.html</welcome-file> <welcome-file>jsp/welcome.jsp</welcome-file> </welcome-file-list> </web-app> 如果用户键入的URL不包含servlet名称、JSP页面或其他资源，则不会在应用目录中找到main.html文件，这时就会显示jsp目录下的welcome.jsp文件。

web.xml – mime-mapping

web.xml – mime-mapping 关联文件与MIME类型服务器一般都具有一种让Web站点管理员将文件扩展名与媒体相关联的方法。例如，将会自动给予名为mom.jpg的文件一个image/jpeg的MIME 类型。但是，假如你的Web应用具有几个不寻常的文件，你希望保证它们在发送到客户机时分配为某种MIME类型。mime-mapping元素 (具有 extension和mime-type子元素) 可提供这种保证。例如，下面的代码指示服务器将application/x-fubar的MIME类型分配给所有以.foo结尾的文件。 foo application/x-fubar 或许，你的Web应用希望重载 (override) 标准的映射。例如，下面的代码将告诉服务器在发送到客户机时指定.ps文件作为纯文本 (text/plain) 而不是作为PostScript (application/postscript) 。 ps application/postscript TOMCAT在默认情况下下载.rar的文件是把文件当作text打开,以至于IE打开RAR文件为乱码,如果遇到这种情况时不必认为是浏览器的问题,大多数浏览器应该不会死皮赖脸地把二进制文件当作文本打开,一般都是服务器给什么浏览器就开什么.解决方法: ...

web.xml

web.xml web.xml template servlet 2.5 <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"> web.xml 3.0: http://www.wiloon.com/?p=3484 <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1" metadata-complete="false"> <display-name>Servlet 3.x Demo</display-name> <description>A demo for servlet 3.x</description> <servlet> <servlet-name>HelloWorld</servlet-name> <servlet-class>com.wiloon.test.servlet.HelloWorld</servlet-class> </servlet> <servlet-mapping> <servlet-name>HelloWorld</servlet-name> <url-pattern>/servlet/HelloWorld</url-pattern> </servlet-mapping> </web-app> web.xml是传统的部署描述文件。 servlet 3.x 中web.xml 变为可选配置. ...

Resin

Resin Resin是CAUCHO公司的产品，是一个非常流行的application server，对servlet和JSP提供了良好的支持，性能也比较优良，resin自身采用JAVA语言开发。

MIME

MIME 媒体类型, 用途互联网邮件扩展 (MIME，Multipurpose Internet Mail Extensions) 是一个互联网标准, 它扩展了电子邮件标准，使其能够支持非ASCII字符、二进制格式附件等多种格式的邮件消息。HTTP协议中也使用了MIME的框架。MIME是通过标准化电子邮件报文的头部的附加域 (fields) 而实现的；这些头部的附加域，描述新的报文类型的内容和组织形式。内容类型 (Content-Type) ，这个头部领域用于指定消息的类型。一般以下面的形式出现。 type有下面的形式。 Text: 用于标准化地表示的文本信息，文本消息可以是多种字符集和或者多种格式的； Multipart: 用于连接消息体的多个部分构成一个消息，这些部分可以是不同类型的数据； Application: 用于传输应用程序数据或者二进制数据； Message: 用于包装一个E-mail消息； Image: 用于传输静态图片数据； Audio: 用于传输音频或者音声数据； Video: 用于传输动态影像数据，可以是与音频编辑在一起的视频数据格式。 subtype 用于指定 type 的详细形式。 text/plain (纯文本) text/html (HTML文档) application/xhtml+xml (XHTML文档) image/gif (GIF图像) image/jpeg (JPEG图像) 【PHP中为: image/pjpeg】 image/png (PNG图像) 【PHP中为: image/x-png】 video/mpeg (MPEG动画) application/octet-stream (任意的二进制数据) application/pdf (PDF文档) application/msword (Microsoft Word文件) message/rfc822 (RFC 822形式) multipart/alternative (HTML邮件的HTML形式和纯文本形式，相同内容使用不同形式表示) application/x-www-form-urlencoded (使用HTTP的POST方法提交的表单) multipart/form-data (同上，但主要用于表单提交时伴随文件上传的场合) parameter可以用来指定附加的信息，更多情况下是用于指定text/plain和text/htm等的文字编码方式的charset参数。MIME根据type制定了默认的subtype，当客户端不能确定消息的subtype的情况下，消息被看作默认的subtype进行处理。Text默认是text/plain，Application默认是application/octet-stream而Multipart默认情况下被看作multipart/mixed。内容传输编码内容传输编码 (Content-Transfer-Encoding) ，这个区域使指定ASCII以外的字符编码方式成为可能。形式如下: ...

从 HTTP GET 和 POST 的区别说起

从 HTTP GET 和 POST 的区别说起 HTTP 定义了与服务器交互的不同方法，最基本的方法是 GET 和 POST. 面试时得到的回答大多是: POST 是安全的，因为被提交的数据看不到，或者被加密的，其它的还有 GET 的时候中文出现乱码 (在地址栏里) ，数据最大长度限制等等。说 POST 比 GET 安全肯定是错的，POST 跟 GET 都是明文传输，用httpfox等插件，或者像WireShark 等类似工具就能观察到。 POST 和 GET 的差别其实是很大的。语义上，GET 是获取指定URL上的资源，是读操作，重要的一点是不论对某个资源 GET 多少次，它的状态是不会改变的，在这个意义上，我们说 GET 是安全的 (不是被密码学或者数据保护意义上的安全) 。因为 GET 是安全的，所以 GET 返回的内容可以被浏览器， Cache 服务器缓存起来 (其中还有很多细节，但不影响这里的讨论) 。而 POST 的语意是对指定资源"追加/添加"数据，所以是不安全的，每次提交的 POST，参与的代码都会认为这个操作会修改操作对象资源的状态，于是，浏览器在你按下 F5 的时候会跳出确认框，缓存服务器不会缓存 POST 请求返回内容。很遗憾到目前为止没有应聘者能够提到这一点。我猜测这背后的原因大概有两个，一是也许大多数人往往 (我也一样) 满足于只要完成任务就好，不管用哪个，表单提交了，数据处理了，内容显示或者重新定向到另外一个页面，就算完成了一个任务，从任务表里划掉，结束。而且对大部分项目(OA, CRM, MIS)的大部分情况下，用哪个似乎都可以。同时，在被商业机构在媒体和书籍上宣传兜售的 WS-* 概念和使用集成开发环境提供的"方便"的代码生成工具后，“了解"到所有 Web 服务调用都是通过 POST，更潜意识里确定了 POST 和 GET 是一样的，而且 GET 能做的，POST 都能做，POST 简直就是 GET++ 嘛。自然，能用 POST 就用 POST，不必在乎两者的差别了。 ...

Java web 乱码

Java web 乱码 http://www.jb51.net/web/12714.html (一) get提交 1.首先说下客户端 (浏览器) 的form表单用get方法是如何将数据编码后提交给服务器端的吧。对于get方法来说，都是把数据串联在请求的url后面作为参数，如: http://localhost:8080/servlet?msg=abc (很常见的一个乱码问题就要出现了，如果url中出现中文或其它特殊字符的话，如: http://localhost:8080 /servlet?msg=杭州，服务器端容易得到乱码) ，url拼接完成后，浏览器会对url进行URL encode，然后发送给服务器，URL encode的过程就是把部分url做为字符，按照某种编码方式 (如: utf-8,gbk等) 编码成二进制的字节码，然后每个字节用一个包含3个字符的字符串 “%xy” 表示，其中xy为该字节的两位十六进制表示形式。我这里说的可能不清楚，具体介绍可以看下java.net.URLEncoder。了解了 URL encode的过程，我们能看到2个很重要的问题，第一: 需要URL encode的字符一般都是非ASCII的字符 (笼统的讲) ，再通俗的讲就是除了英文字母以外的文字 (如: 中文，日文等) 都要进行URL encode，所以对于我们来说，都是英文字母的url不会出现服务器得到乱码问题，出现乱码都是url里面带了中文或特殊字符造成的；第二: URL encode到底按照那种编码方式对字符编码？这里就是浏览器的事情了，而且不同的浏览器有不同的做法，中文版的浏览器一般会默认的使用GBK，通过设置浏览器也可以使用UTF-8，可能不同的用户就有不同的浏览器设置，也就造成不同的编码方式，所以很多网站的做法都是先把url里面的中文或特殊字符用 javascript做URL encode，然后再拼接url提交数据，也就是替浏览器做了URL encode，好处就是网站可以统一get方法提交数据的编码方式。完成了URL encode，那么现在的url就成了ASCII范围内的字符了，然后以iso-8859-1的编码方式转换成二进制随着请求头一起发送出去。这里想多说几句的是，对于get方法来说，没有请求实体，含有数据的url都在请求头里面，之所以用URL encode，我个人觉的原因是: 对于请求头来说最终都是要用iso-8859-1编码方式编码成二进制的101010…..的纯数据在互联网上传送，如果直接将含有中文等特殊字符做iso-8859-1编码会丢失信息，所以先做URL encode是有必要的。 2。服务器端 (tomcat) 是如何将数据获取到进行解码的。第一步是先把数据用iso-8859-1进行解码，对于get方法来说，tomcat获取数据的是ASCII范围内的请求头字符，其中的请求url里面带有参数数据，如果参数中有中文等特殊字符，那么目前还是URL encode后的%XY状态，先停下，我们先说下开发人员一般获取数据的过程。通常大家都是request.getParameter(“name”)获取参数数据，我们在request对象获得的数据都是经过解码过的，而解码过程中程序里是无法指定，这里要说下，有很多新手说用 request.setCharacterEncoding(“字符集”)可以指定解码方式，其实是不可以的，看servlet的官方API说明有对此方法的解释: Overrides the name of the character encoding used in the body of this request. This method must be called prior to reading request parameters or reading input using getReader().可以看出对于get方法他是无能为力的。那么到底用什么编码方式解码数据的呢，这是tomcat的事情了，默认缺省用的是 iso-8859-1,这样我们就能找到为什么get请求带中文参数为什么在服务器端得到乱码了，原因是在客户端一般都是用UTF-8或GBK对数据 URL encode，这里用iso-8859-1方式URL decoder显然不行，在程序里我们可以直接 ...

tomcat server.xml

tomcat server.xml http://www.importnew.com/26156.html Tomcat隶属于Apache基金会，是开源的轻量级Web应用服务器，使用非常广泛。server.xml是Tomcat中最重要的配置文件，server.xml的每一个元素都对应了Tomcat中的一个组件；通过对xml文件中元素的配置，可以实现对Tomcat中各个组件的控制。因此，学习server.xml文件的配置，对于了解和使用Tomcat至关重要。本文将通过实例，介绍server.xml中各个组件的配置，并详细说明Tomcat各个核心组件的作用以及各个组件之间的相互关系。说明: 由于server.xml文件中元素与Tomcat中组件的对应关系，后文中为了描述方便，“元素"和"组件"的使用不严格区分。一、一个server.xml配置实例 server.xml位于$TOMCAT_HOME/conf目录下；下面是一个server.xml实例。后文中将结合该实例讲解server.xml中，各个元素的含义和作用；在阅读后续章节过程中，可以对照该xml文档便于理解。 <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" /> </Host> </Engine> 二、server.xml文档的元素分类和整体结构 ...

Tomcat Port 8009 与AJP13协议

Tomcat Port 8009 与AJP13协议由于tomcat的html和图片解析功能相对其他服务器如apche等较弱，所以，一般都是集成起来使用，只有jsp和servlet服务交由tomcat处理，而tomcat和其他服务器的集成，就是通过ajp协议来完成的。 AJP13(Apache JServ Protocol version 1.3)是定向包协议。因为性能原因，使用二进制格式来传输可读性文本。WEB服务器通过TCP连接和SERVLET容器连接。为了减少进程生成 socket的花费，WEB服务器和SERVLET容器之间尝试保持持久性的TCP连接，对多个请求/回复循环重用一个连接。一旦连接分配给一个特定的请求，在请求处理循环结束之前不会在分配。换句话说，在连接上，请求不是多元的。这个是连接两端的编码变得容易，虽然这导致在一时刻会有很多连接。一旦WEB服务器打开了一个到SERVLET容器的连接，连接处于下面的状态: ◆ 空闲这个连接上没有处理的请求。 ◆ 已分派连接正在处理特定的请求。一旦一个连接被分配给一个特定的请求，在连接上发送的基本请求信息是高度压缩的。在这点，SERVLET容器大概准备开始处理请求，当它处理的时候，它能发回下面的信息给WEB服务器: ◆ SEND_HEADERS 发送一组头到浏览器。 ◆ SEND_BODY_CHUNK 发送一块主体数据到浏览器。 ◆ GET_BODY_CHUNK 从请求获得下一个数据如果还没有全部传输完，如果请求内容的包长度非常大或者长度不确定，这是非常必要的。例如上载文件。注意这和HTTP的块传输没有关联。 ◆ END_RESPONSE 结束请求处理循环。 Tomcat服务器通过Connector连接器组件与客户程序建立连接，Connector组件负责接收客户的请求，以及把Tomcat服务器的响应结果发送给客户。默认情况下，Tomcat在server.xml中配置了两种连接器: <!- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 -> <!- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -> 第一个连接器监听8080端口，负责建立HTTP连接。在通过浏览器访问Tomcat服务器的Web应用时，使用的就是这个连接器。第二个连接器监听8009端口，负责和其他的HTTP服务器建立连接。在把Tomcat与其他HTTP服务器集成时，就需要用到这个连接器。 Web客户1直接访问Tomcat服务器上的JSP组件，他访问的URL为http://localhost:8080 /index.jsp。Web客户2通过HTTP服务器访问Tomcat服务器上的JSP组件。假定HTTP服务器使用的HTTP端口为默认的80端口，那么Web客户2访问的URL为http://localhost:80/index.jsp 或者 http://localhost/index.jsp。摘自: http://hikin.iteye.com/blog/555682 2.http://bbs.163jsp.com/posts/list/472.html http://tomcat.apache.org/connectors-doc-archive/jk2/common/AJPv13.html

tomcat 8005

tomcat 8005 http://www.wellho.net/mouth/837_Tomcat-Shutdown-port.html On a new installation of Tomcat (default config files), you’ll notice that your server.xml file is set up with a shutdown port of 8005, and shutdown=“SHUTDOWN”. What does this mean? It means that anyone who contacts the server locally on port 8005 and send it the words SHUTDOWN can cause Tomcat to close out all its web applications and shut down cleanly. Yikes - is this a security hole of what? It could be. Fortunatly , you'll notice that I said it's a LOCAL connection to the port that causes a shutdown, so it no-one can ssh or telnet in, nor log in from the keyboard unless they're an admin, it might not be a problem .... If your Tomcat server allows anyone except the administrator to log in with a shell, then I strongly suggest you change shutdown="SHUTDOWN" to shutdown="waSS-I41tis" so that at least it won't be a string that any hacker can guess.<del> You might like to change the port number too. Alas, it would be unwise to disable the facility completely, since catalina.sh and shutdown.sh use the port (details read from the config file) as part of their processing. At least server.xml is neither group nor world readable.</del>

当装了两个tomcat后，修改tomcat端口

当装了两个tomcat后，修改tomcat端口 http://zfsn.iteye.com/blog/669901 修改Tomcat的端口号: 在默认情况下，tomcat的端口是8080，如果出现8080端口号冲突，用如下方法可以修改Tomcat的端口号: 首先: 在Tomcat的根 (安装) 目录下，有一个conf文件夹，双击进入conf文件夹，在里面找到Server.xml文件，打开该文件。其次: 在文件中找到如下文本: 也有可能是这样的: 等等；最后: 将port=“8080"改为其它的就可以了。如port=“8081"等。保存server.xml文件，重新启动Tomcat服务器，Tomcat就可以使用8081端口了。注意，有的时候要使用两个tomcat，那么就需要修改其中的一个的端口号才能使得两个同时工作。修改了上面的以后，还要修改两处: (1) 将的8009改为其它的端口。 (2) 继续将<Server port="8005" shutdown="SHUTDOWN" debug="0">的8005改为其它的端口。经过以上3个修改，应该就可以了。 8443

Tomcat basic

Tomcat basic archlinux sudo pacman -S tomcat8 http://baike.baidu.com/view/10166.htm tomcat 7 https://archive.apache.org/dist/tomcat/tomcat-7 Tomcat是Apache 软件基金会 (Apache Software Foundation) 的Jakarta 项目中的一个核心项目，由Apache、Sun 和其他一些公司及个人共同开发而成。由于有了Sun 的参与和支持，最新的Servlet 和JSP 规范总是能在Tomcat 中得到体现，Tomcat 5 支持最新的Servlet 2.4 和JSP 2.0 规范。因为Tomcat 技术先进、性能稳定，而且免费，因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可，成为目前比较流行的Web 应用服务器。 Tomcat 很受广大程序员的喜欢，因为它运行时占用的系统资源小，扩展性好，支持负载平衡与邮件服务等开发应用系统常用的功能；而且它还在不断的改进和完善中，任何一个感兴趣的程序员都可以更改它或在其中加入新的功能。 Tomcat 是一个轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。对于一个初学者来说，可以这样认为，当在一台机器上配置好Apache 服务器，可利用它响应对HTML 页面的访问请求。实际上Tomcat 部分是Apache 服务器的扩展，但它是独立运行的，所以当你运行tomcat 时，它实际上作为一个与Apache 独立的进程单独运行的。这里的诀窍是，当配置正确时，Apache 为HTML页面服务，而Tomcat 实际上运行JSP 页面和Servlet。另外，Tomcat和IIS、Apache等Web服务器一样，具有处理HTML页面的功能，另外它还是一个Servlet和JSP容器，独立的Servlet容器是Tomcat的默认模式。不过，Tomcat处理静态HTML的能力不如Apache服务器。目前Tomcat最新版本为7.0.27 Released。名称的由来 Tomcat最初是由Sun的软件构架师詹姆斯·邓肯·戴维森开发的。后来他帮助将其变为开源项目，并由Sun贡献给Apache软件基金会。由于大部分开源项目O’Reilly都会出一本相关的书，并且将其封面设计成某个动物的素描，因此他希望将此项目以一个动物的名字命名。因为他希望这种动物能够自己照顾自己，最终，他将其命名为Tomcat (英语公猫或其他雄性猫科动物) 。而O’Reilly出版的介绍Tomcat的书籍 (ISBN 0-596-00318-8) 1的封面也被设计成了一个公猫的形象。而Tomcat的Logo兼吉祥物也被设计成了一只公猫。版本差异 (主要版本) Apache Tomcat 7.x 是目前的开发焦点。它在汲取了Tomcat 6.0.x优点的基础上，实现了对于Servlet 3.0、JSP 2.2和EL 2.2等特性的支持。除此以外的改进列表如下: · Web应用内存溢出侦测和预防 · 增强了管理程序和服务器管理程序的安全性 · 一般 CSRF保护 ...

content-type

content-type Content-Type 实体头部用于指示资源的 MIME 类型 media type Content-Type (内容类型），一般是指网页中存在的 Content-Type，用于定义网络文件的类型和网页的编码，决定浏览器将以什么形式、什么编码读取这个文件 Content-Type 标头告诉客户端实际返回的内容的内容类型。语法格式： Content-Type: text/html; charset=utf-8 Content-Type: multipart/form-data; boundary=something charset 字符编码标准。常见的媒体格式类型如下： text/html ： HTML格式 text/plain ：纯文本格式 text/xml ： XML格式 image/gif ：gif图片格式 image/jpeg ：jpg图片格式 image/png：png图片格式以application开头的媒体格式类型： application/xhtml+xml ：XHTML格式 application/xml： XML数据格式 application/atom+xml ：Atom XML聚合格式 application/json： JSON数据格式 application/pdf：pdf格式 application/msword ： Word文档格式 application/octet-stream ：二进制流数据 (如常见的文件下载） application/x-www-form-urlencoded ： <form encType=""> 中默认的encType，form 表单数据被编码为 key/value 格式发送到服务器 (表单默认的提交数据的格式）另外一种常见的媒体格式是上传文件之时使用的： multipart/form-data ：需要在表单中进行文件上传时，就需要使用该格式 application/json: Official MIME type for json ...

axios

axios 模拟form 提交 Content-Type: multipart/form-data import axios from 'axios' let data = new FormData(); data.append('code','1234'); data.append('name','yyyy'); axios.post(`${this.$url}/test/testRequest`,data) .then(res=>{ console.log('res=>',res); }) https://segmentfault.com/a/1190000015261229

overflow, hidden

overflow, hidden 核心提示: overflow:hidden这个CSS样式是大家常用到的CSS样式，但是大多数人对这个样式的理解仅仅局限于隐藏溢出，而对于清除浮动这个含义不是很了解。 overflow:hidden这个CSS样式是大家常用到的CSS样式，但是大多数人对这个样式的理解仅仅局限于隐藏溢出，而对于清除浮动这个含义不是很了解。一提到清除浮动，我们就会想到另外一个CSS样式: clear:both，我相信对于这个属性的理解大家都不成问题的。但是对于"浮动"这个词到底包含什么样的含义呢？我们下面来详细的阐述一下。这是一个常用的div写法，下面我们来书写样式。大家可以在DMX中自己做试验 #wai{ width:500px; background:#000; height:500px;} #nei { float:left; width:600px; height:600px; background:red;} 可以看到，我给nei这个id加了一个浮动，我们常规的理解是，我们允许nei这个id的div的右边出现其他的内容，只要它的宽度不超过wai这个div和nei这个div的剩余值。如果div wai中还包含其他的div，我不允许它出现在nei的右侧，我们则用样式clear:both指定这个div，不允许它浮动在nei右侧。这些在ie6里面是正确的。但是在火狐或者其他浏览器里面，我们发现问题并非如此简单。我们发现，当nei这个div的宽度和高度都大于wai这个div的时候，wai并没有被内撑开而是依旧显示为我们指定的宽高。在我的例子中，都是500。这个时候我不理解了，我搜索了很多的资料，但是都没能理解这是为什么，直到看到别人在类似的情况下给wai这个div加了一个overflow:hidden这个属性解决了这个问题。我们直到overflow:hidden这个属性的作用是隐藏溢出，给wai加上这个属性后，我们的nei的宽高自动的被隐藏掉了。另外，我们再做一个试验，将wai这个div的高度值删除后，我们发现，wai的高度自动的被nei这个div的高度值给撑开了。说到这里，我们再来理解一下"浮动"这个词的含义。我们原先的理解是，在一个平面上的浮动，但是通过这个试验，我们发现，这不仅仅是一个平面上的浮动，而是一个立体的浮动！也就是说，当nei这个div加上浮动这个属性的时候，在显示器的侧面，它已经脱离了wai这个div，也就是说，此时的nei的宽高是多少，对于已经脱离了的wai来说，都是不起作用的。打个形象的比喻就是当JJ脱离BB的时候，JJ的大小对于BB是没有撑开的作用的 (有点少儿不宜的感觉-_-|||) OK，当我们全面的理解了浮动这个词的含义的时候，我们就理解overflow:hidden这个属性中的解释，清除浮动是什么意思了。也就是说，当我们给wai这个div加上overflow:hidden这个属性的时候，其中的nei等等带浮动属性的div的在这个立体的浮动已经被清除了，就好比JJ又进入了BB内，JJ的大小自然又会影响到BB的大小。这就是overflow:hidden这个属性清除浮动的准确含义。当我们没有给wai这个div设置高度的时候，nei这个div的高度，就会撑开wai这个div，而在另一个方面，我们要注意到的是，当我们给wai这个div加上一个高度值，那么无论nei这个div的高度是多少，wai这个高度都是我们设定的值。而当nei的高度超过wai的高度的时候，超出的部分就会被隐藏。这就是隐藏溢出的含义！我相信，通过我的这些文字，大家对overflow:hidden这个属性有了全新的认识。希望大家和我一样，在div+css学习中能够不断的进步！ (PS: 本人是div+css的初学者，请高手不要嘲笑。困惑这个属性已经很久，网上的资料大多不怎么理想，因此才写这些文字献丑。本文为地方网络工作室原创。转载请保留本工作室链接，文章首发: http://www.difangla.com/Html/jishu/css/88140.html)

css垂直居中

css垂直居中单行内容的居中只考虑单行是最简单的，无论是否给容器固定高度，只要给容器设置 line-height 和 height，并使两值相等，再加上 over-flow: hidden 就可以了 [css] .middle-demo-1{ height: 4em; line-height: 4em; overflow: hidden; } [/css] 优点: 同时支持块级和内联极元素支持所有浏览器缺点: 只能显示一行 IE中不支持等的居中要注意的是: 使用相对高度定义你的 height 和 line-height 不想毁了你的布局的话，overflow: hidden 一定要加上。