get和post请求的区别
get请求暴露参数在地址栏,post不会
get请求方式数据有长度限制 post长度没有,可用文件上传的功能
** web核心知识
servlet
servlet是处理请求和响应的Java程序
创建servlet需要继承HttpServlet类,在web.xml文件中配置
servlet中的细节
servlet的生命周期
何时创建: 默认第一次访问servlet时创建该对象 或 如果配置了,启动时加载
当客户端向tomcat发送http请求访问servelt程序,tomcat首先会解析请求,检查内存中是否已经有了该servlet对象:
如果有直接使用对应的servlet对象;
如果没有就创建servlet实例对象,然后通过调用init() 方法实现Servlet的初始化工作。
需要注意的是,在整个servlet的生命周期内,init方法只被调用了一次。
何时销毁: 服务器关闭servlet就销毁了
每次访问必然执行的方法:service(ServletRequest req, ServletResponse res)方法
在这个阶段,tomcat服务器会为这个请求 创建 代表HTTP请求的ServletRequest对象 和 代表HTTP响应的 ServletResponse对象,然后将他们作为参数传递给service() 方法。
servcie() 方法从ServletRequest对象获取请求的信息并做出处理;通过ServletResponse 对象生成响应的结果。
在servlet的整个生命周期内,对于servlet的每一次访问请求,tomcat都会调用servlet的service方法,并且创建新的ServletRequest对象和ServletResponse对象。也就是说service() 方法会servlet的生命周期内会被调用多次。
doGet和doPost由service方法调用:在我们写的servlet父类HttpServlet中源码:
servlet配置
在配置url-pattern中 可分为三种配置方式
1>完全匹配 : /Servlet
2>目录匹配:/aaa/bbb/* /虚拟路径/* *代表任意
3>扩展名匹配 :格式:*.扩展名 *.asd
第二种和第三种不能混着用
服务器启动实例化Servlet配置
servlet何时创建: 默认第一次访问时创建
当在servlet的配置时 加上一个配置 servlet对象在服务器启动 时就创建
缺省Servlet
当url-pattern 配置一个 / ,代表该servlet是缺省的servlet
当你访问资源地址与所有的servlet都不匹配时,缺省的servlet负责处理
web应用中所有的资源的响应都是servlet负责的,包括静态资源
ServletContext
servletContext代表一个web应用的环境(上下文)对象,内部封装的该web应用的信息,,一个web应用只有一个ServletContext对象,可以有多个servlet。
ServletContext的生命周期
创建: 该web应用被加载(服务器启动或发布web应用(前提是服务器启动状态))
销毁:web应用被卸载(服务器关闭,移除web应用)
获取ServletContext对象
1)ServletContext servletContext = config.getServletContext();
2)ServletContext servletContext = this.getServletContext();
ServletContext的作用
1>获取web应用全局的初始化参数
通过context对象获取参数
2>获取web应用中任何资源的绝对路径
方法:String path = context.getRealPath(相对于该web应用的相
ServletContext 是一个域对象
存储数据的区域就是域对象,
ServletContext 域对象作用的范围:整个web应用(所有的web资源都可以在域中存取数据,数据可以共享)
ServletConfig
每一个servlet对应一个独立的ServletConfig 对象
服务器创建servlet的同时,再去创建一个servletConfig对象,包含了一些servlet的配置信息
再调用servlet的init方法时,将servletConfig传给servlet
servletConfig的内容是 是自己定义的. 在web.xml中 的servlet标签下书写servletConfig的内容.
读取配置信息
- 如果servlet需要一些参数,可以在web.xml的servlet标签中配置
- tomcat去工作: 读取servlet中init-param这个标签. 把里面的内容封装到ServletConfig中
- tomcat去工作: 调用servlet的init方法, 把封装好的 servletConfig对象, 传递给servlet中
- 如何使用
获取servletConfig对象, 通过servlet的getServletConfig() 方法
response
状态码和响应头的设置
设置状态码: setStatus(int i);
设置响应头信息
setHeader(String name,String value)
Refresh: 3;url=http://www.jd.com (页面自动刷新3秒)
1.1.1 Location: http://www.it315.org/index.jsp // 通常告知浏览器 马上向该地址发送请求 通常 和 302 一起使用!!
请求转发和重定向的区别
转发的地址栏不变,重定向变
转发操作是发生在服务器内部,重定向是浏览器行为
转发是一次请求完成,重定向是两次请求
转发还能访问requ域中的数据,重定向不能
请求转发的效率比重定向的效率高一点
转发只能访问当前服务器项目,重定向可以随便访问。
Content-Type: text/html; charset=utf-8 告诉浏览器以什么样的方式打开资源,和使用编码集
响应体
应用场景: 浏览器显示的内容, 下载文件等.
response 以流的形式,将内容输出给浏览器
response.getWriter() 获取响应体的字符输出流,输出页面的时候使用
response.getOutputStream() 获取响应体的字节输出流,输出文件(图片,avi等。。。。)的时候使用
注意问题:
1 文件数据传输: getOutputStream 手动生成响应内容时 使用 getWriter
2 getOutputStream 和 getWriter 相互排斥,不能同时使用,否则会冲突.
3 tomcat会自动调用response输出流的 close方法和flush方法, 因此不需要我们手动关闭流.
问题1 :ServletContext的getContext(),getContextPath(),getRealPath() 以及HttpServletRequst的getContextPath(),getRequestURI() getRequestURL() getServletPath() 这些方法获得路径有什么区别和联系
答: ServletContext
getContext() :获取指定路径的项目,它的ServletContext对象,但是,处于安全考虑,如果获取其他的项目ServletContext都会拿到null,所以方法不常用
getContextPath():获取当前项目根路径
getRealPath():获取当前项目中,指定资源的路径
HttpServletRequst:
getContextPath():获取当前项目根路径(同上)
getRequestURI(): 获取请求地址,不包含协议,地址,端口
getRequestURL(): 获取请求地址,包含协议,地址,端口
问题2 :ServletContext 与Servlet的在服务器中存在形式被称为什么? 使用ServletContext会出现并发问题么?如何解决
答:1 对象
ServletContext tomcat在底层的实现类是org.apache.catalina.core.ApplicationContextFacade,这是一个容器存取数据的
Servlet 是处理请求和响应的对象,由我们自己实现
2 ServletContext对象在存取数据的时候使用ConcurrentHashMap,线程安全。
request
1 如果获取请求 行 头 体
2 请求中文处理
3 请求对象的其他常用方法
方法
获取请求放法的类型 getMethod();
获取请求的路径:getRequestURL();
获取请求协议:getProtocol();
获取IP地址:getRemoteAddr();
获取端口号:get LocalPort();
获取请求头:getHeader();
获取请求参数:getParameter();
请求参数乱码处理
第一种方案:修改tomcat默认的编码方式 (不推荐 )
修改tomcat下的conf/server.xml文件
找到如下代码:
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
修改完成后:
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" />
第二种方案:先编码再解码(重点)
parameter = new String(parameter.getBytes(“iso8859-1”),”UTF-8”);
post请求编码
request.setCharacterEncoding();
作为域对象
setAttribute();getAttribute();removeAttribute();
请求转发
当一个Web资源收到客户端的请求后,如果希望服务器通知另外一个资源处理.
可以通过 转发对象 RequestDispatcher 对象的forward(request,response)方法,将当前请求传递给其他的Web资源进行处理,这种方式称为请求转发。
在这些转发的过程中,所有的Servle共享同一个请求对象。
在转发中,客户端是感觉不到服务器内部在跳转。而且客户端的浏览器的地址栏中是不会发生任何变化的
因为在多个Servlet中可以进行转发,导致多个Servlet之间共享同一个request对象,于是在发出转发的Servlet中,可以把request对象当做一个容器,然后给其中保存数据,在其他的Servlet中可以取出前面的Servlet给request对象中保存的数据。
request对象如果当做容器的话,它只是在当前这次请求中有效。当请求响应结束了,这个容器就消失了。
Session和Cookie
会话技术
从打开一个浏览器访问某个站点,到关闭这个浏览器的整个过程,成为一次会话。会 话技术就是记录这次会话中客户端的状态与数据的。
会话技术分为Cookie和Session:
Cookie:数据存储在客户端本地,减少服务器端的存储的压力,安全性不好,客户端 可以清除cookie
Session:将数据存储到服务器端,安全性相对好,增加服务器的压力
cookie
Cookie技术是将用户的数据存储到客户端的技术,我们分为两方面学习:
第一,服务器端怎样将一个Cookie发送到客户端
第二,服务器端怎样接受客户端携带的Cookie
1)创建Cookie:
Cookie cookie = new Cookie(String cookieName,String cookieValue);
示例:
Cookie cookie = new Cookie(“username”,“zhangsan”);
那么该cookie会以响应头的形式发送给客户端:
注意:Cookie中不能存储中文
2)设置Cookie在客户端的持久化时间:
cookie.setMaxAge(int seconds); —时间秒
注意:如果不设置持久化时间,cookie会存储在浏览器的内存中,浏览器关闭 cookie信息销毁(会话级别的cookie),如果设置持久化时间,cookie信息会 被持久化到浏览器的磁盘文件里
示例:
cookie.setMaxAge(10*60);
设置cookie信息在浏览器的磁盘文件中存储的时间是10分钟,过期浏览器 自动删除该cookie信息
3)设置Cookie的携带路径:
cookie.setPath(String path);
注意:如果不设置携带路径,那么该cookie信息会在访问产生该cookie的 web资源所在的路径都携带cookie信息
示例:
cookie.setPath("/WEB16");
代表访问WEB16应用中的任何资源都携带cookie
cookie.setPath("/WEB16/cookieServlet");
代表访问WEB16中的cookieServlet时才携带cookie信息
4)向客户端发送cookie:
response.addCookie(Cookie cookie);
5)删除客户端的cookie:
如果想删除客户端的已经存储的cookie信息,那么就使用同名同路径的持久化时 间为0的cookie进行覆盖即可
服务器端怎么接受客户端携带的Cookie
cookie信息是以请求头的方式发送到服务器端的
1)通过request获得所有的Cookie:
Cookie[] cookies = request.getCookies();
2)遍历Cookie数组,通过Cookie的名称获得我们想要的Cookie
for(Cookie cookie : cookies){
if(cookie.getName().equal(cookieName)){
String cookieValue = cookie.getValue();
}
}
总结
Cookie技术:存到客户端
发送cookie
Cookie cookie = new Cookie(name,value)
cookie.setMaxAge(秒)
cookie.setPath()
response.addCookie(cookie)
获得cookie
Cookie[] cookies = request.getCookies();
cookie.getName();
cookie.getValue();
session
session生命周期
创建:第一次指定request.getSession();
销毁:服务器关闭、session失效/过期、手动session.invalidate();
session作用范围:默认一会话中
Session技术:存到服务器端 借助cookie存储JSESSIONID
session钝化和活化
(一)钝化
当服务器正常关闭时,还存活着的session(在设置时间内没有销毁) 会随着服务器的关闭被以文件(“SESSIONS.ser”)的形式存储在tomcat 的work 目录下,这个过程叫做Session 的钝化。
(二)活化
当服务器再次正常开启时,服务器会找到之前的“SESSIONS.ser” 文件,从中恢复之前保存起来的Session 对象,这个过程叫做Session的活化。
1)想要随着Session 被钝化、活化的对象它的类必须实现Serializable 接口,还有要注意的是只有在服务器正常关闭的条件下,还未超时的Session 才会被钝化成文件。当Session 超时、调用invalidate 方法或者服务器在非正常情况下关闭时,Session 都不会被钝化,因此也就不存在活化。
2)在被钝化成“SESSIONS.ser” 文件时,不会因为超过Session 过期时间而消失,这个文件会一直存在,等到下一次服务器开启时消失。
3)当多个Session 被钝化时,这些被钝化的Session 都被保存在一个文件中,并不会为每个Session 都建立一个文件。
3)当服务器非正常情况下关闭时(超时、调用invalidate 方法),Session 不会被钝化,
session和cookie的区别
cookie机制采用的是在客户端保持状态的方案,而session机制采用的是在服务器端保持状态的方案。
由于采用服务器端保持状态的方案在客户端也需要保存一个标识,所以session机制可能需要借助于cookie机制
来达到保存标识的目的
把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器
会自动修改表单,添加一个隐藏字段,以便在表单提交时能够把session id传递回服务器。比如:
<form name="testform" action="/xxx">
<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
<input type="text">
</form>
1、cookie数据存放在客户的浏览器上,session数据放在服务器上。
2、cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能
考虑到减轻服务器性能方面,应当使用COOKIE。
4、单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
5、建议:
将登陆信息等重要信息存放为SESSION
其他信息如果需要保留,可以放在COOKIE中
session失效的30分钟怎么计算
在生成session的时候,会设置一个session过期时间。session的过期时间并不是从生成session对象开始计算,超过过期时间,session就失效了。
而是每当一个浏览器请求,session生存时间就会刷新,最后一次浏览器请求,超过过期时间,没有浏览器请求到达,session就会过期。
关闭浏览器session是否销毁
当用户第一次访问Web应用中支持Session的某个网页时,就会开始一个新的Session,
那么接下来当用户浏览这个Web应用的不同网页时,始终处于一个Session中
再详细些:
当一个Session开始时,Servlet容器会创建一个HttpSession对象,那么在HttpSession对象中,可以存放用户状态的信息
Servlet容器为HttpSession对象分配一个唯一标识符即Sessionid,Servlet容器把Sessionid作为一种Cookie保存在客户端的 浏览器 中
用户每次发出Http请求时,Servlet容器会从HttpServletRequest对象中取出Sessionid,然后根据这个Sessionid找到相应的HttpSession对象,从而获取用户的状态信息
以上就是Session的运行机制,
我们关闭浏览器后,就再也访问不到之前的session了是因为:
之前的Session一直都在服务器端,而当我们关闭浏览器时,此时的Cookie是存在于浏览器的进程中的,当浏览器关闭时,Cookie也就不存在了。cookie一种是存在硬盘中,一种存在浏览器的进程中
而session的Cookie是存在于浏览器的进程中,那么这种Cookie我们称为会话Cookie,
当我们重新打开浏览器窗口时,之前的Cookie中存放的Sessionid已经不存在了,此时服务器从HttpServletRequest对象中没有检查到sessionid,服务器会再发送一个新的存有Sessionid的Cookie到客户端的浏览器中,此时对应的是一个新的会话,而服务器上原先的session等到它的默认时间到之后,便会自动销毁。
当在同一个浏览器中同时打开多个标签,发送同一个请求或不同的请求,仍是同一个session;
当不在同一个窗口中打开相同的浏览器时,发送请求,仍是同一个session;
当使用不同的浏览器时,发送请求,即使发送相同的请求,是不同的session;
当把当前某个浏览器的窗口全关闭,再打开,发起相同的请求时,是不同的session,但是它和session的生命周期是没有关系的.