我的理解：http协议中302和303的区别

http1.0协议中只有302码，没有303状态码；
http1.1,在默认情况下，很多服务端基础程序，为了兼容http1.0，在遇到本应响应303时，也给客户端响应了302。

碰到的问题：

场景: 在整个web系统使用https的情况下，在程序中使用了redirect，结果发现redirect之后的重定向请求变成了http，此时redirect的响应码为302.

 

问 题：由于整个应用嵌入的需求，在页面组合上使用了iframe，整个网站包括父页面和iframe的子应用的所有请求均使用的https协议，而在 iframe子应用的redirect请求之后出现了http请求，在ie和firefox等浏览器中，并没有问题，（因为它们把iframe子应用中的 http请求也照样上送到了服务器，接收到http请求时，服务端会强制客户端使用https重定向请求），此时，对我们的系统仍然不存在影响（只是多了 一次重定向请求，但是对用户看不到）；

但是在chrome浏览器下，iframe的http请求就被拦截掉了，提示在安全的https环境下不允许使用http访问，造成页面就死在了重定向之前的页面，不能正确的重定向到目标页面去了。
  
       问题看起来很纳闷，但是严格安全限制的浏览器下，问题也很明显。在当时的情况下，也只是看到了现象，至于原因和原理一点都不明白。于是根据现象找解决办 法，我们用的spring mvc，在stackoverflow上面找到了类似的问题。通过设置viewResolver的redirectHttp10Compatible属性 为false，关闭了对http1.0协议的兼容支持，程序的redirect响应码则变为了303，之后的重定向请求则维持了一致的https协议。

     所以，最终发现一个现象，在302和303的状态码下，整个https结构的web系统下，浏览器接收到此两种不同的响应码时，分别使用了http和https去重定向请求。查找网上的理解，

1. 302=<"HTTP/1.1 302Found（or Moved Temporarily）",
2. 303=<"HTTP/1.1 303See Other",

也看不出区别。所以，我的理解：302 响应码是http1.0的标准，在当时还没有支持https的相应协议出现，所以现在的浏览器为了兼容http1.0，在302状态码下，碰到了 https的重定向请求，也会以http去转发；而303是http1.1的标准，浏览器就维持了一致的https的重定向请求了。