cookie系列（二）header302跳转引发的思考

最新推荐文章于 2024-04-26 22:22:35 发布

原创最新推荐文章于 2024-04-26 22:22:35 发布 · 1.9k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#cookie

PHP 专栏收录该内容

62 篇文章

订阅专栏

本文解析了 PHP 中 header 302 跳转的执行机制，包括为何跳转后原文件仍能执行及如何阻止后续执行。同时探讨了 header 302 跳转与 curl 在设置其他站点 cookie 上的不同表现。

今天我们来看以下两个现象，并解释这两个现象的原因：

第一个现象：

php文件运行过程中如果碰到有header("Location:某个页面URL");这种语句，会直接跳转到另一个页面，但是这里的跳转并不会影响当前php文件的继续执行。

下面我们用代码跑一下看看上面的现象是否是成立的：

（1）http://a.com/test.php代码如下：

（2）http://b.com/test.php代码如下：

（3）访问http://a.com/test.php显示以下结果：

此时，我们发现我们显示的结果页中，地址栏变成了b.com/test.php，同时，页面输出了123，然后我们也看到a.com下面cookie被写入成功了，而且a.txt文件也生成了。

实验证明，header302跳转之后，其下面的代码还是会继续执行，那么原因是什么呢？

很多人不明白，不是已经跳转走了吗？跳走了怎么可能还执行？

要解释这个现象其实原理很简单，客户端a向服务端b发送请求，服务端b处理完成之后，响应回客户端a。注意这里面的用词，处理完成！处理完成！处理完成！是服务端b处理完成之后才会响应客户端。

上代码，我们证实一下是不是处理完成之后响应回客户端：

（1）http://a.com/test.php代码如下：

（2）http://b.com/test.php代码不变如下：

（3）访问http://a.com/test.php显示以下结果：

浏览器一直在加载，10秒之后才跳转到http://b.com/test.php页面。

上图中代码写的很清楚，先header跳转然后在sleep（10），页面没有立即跳转而是停了10秒钟再发生跳转。

所以要想header之后代码不继续执行，我们只需要在header后面exit就可以了，代码如下：

那么后面的代码就不会被执行！

到这个地方，我们第一个现象的原因其实已经解释完了，现在我们来看一个细节，http://a.com/test.php代码如下图一所示，访问http://a.com/test.php响应回来的内容为空，见下图二，我们虽然有echo 有print_r还有var_dump，但是都没有被输出。

通过谷歌浏览器，我们看到服务端虽然没有返回内容，但是返回了响应消息头，如下：

此看来，当服务器端在设置header响应报文给客户端的时候，如果状态码是302，那么服务器端就不会返回具体的数据内容给客户端，而浏览器看到302，也不用去关心返回的响应内容，直接拿着响应报文里面的location地址前往下一站去喽，这样的方式也防止了不必要的数据传输。

这让我想到了另一张情况，客户端去情况求服务端的时候，服务端验证请求资源没有发生改变会返回304状态码，那么这个时候服务器端也不会返回响应内容，通过304状态码去告诉浏览器，这个资源没有更改过，你直接从自己的缓存中去拿吧。

我们继续第二个现象：

header 302跳转可以跳转到其他网站设置cookie而curl无法给其他站点设置cookie，这又是为什么？

在之前，我们其实探讨过这个问题jsonp系列（三）两种写法请求后端设置cookie，为啥一个可以，一个不可以？，其中我们讲到了，为什么curl不能跨站设置cookie,但是今天有小伙伴问，为啥，header 跳转能够给其他站点设置cookie呢？

还是先看代码吧：

（1）http://a.com/test.php代码如下：

（2）http://b.com/test.php代码如下：

（3）访问http://a.com/test.php我们发现页面跳转到http://b.com/test.php并且b.com下被设置了cookie。

这又是什么原因呢？

为啥curl不可以,header302却可以？

通过谷歌浏览器我们可以发现：

如图中所示，当我们在地址栏敲下http://a.com/test.php并且敲下回车的时候，通过谷歌浏览器我们发现了两个请求都是test.php，分别如下：

如上图，当浏览器去请求http://a.com/test.php的时候，a.com服务端返回302给浏览器，浏览器拿到响应消息头的location，存到内存中，此时浏览器与http://a.com的通信过程其实就结束了，也就是一个请求与响应就结束了，然后浏览器拿着location地址重新请求http://b.com/test.php，于是我们看到浏览器跳转的画面，此时b。com返回给浏览器的响应消息头里面有set-cookie的信息，那么浏览器得到这个cookie信息生成文件并存放到了浏览器默认cookie存放的目录下。

如图所示：

header跳转的情况：

在第6个步骤中，b.com返回了cookie信息给浏览器，浏览器存下了b.com的cookie信息。

curl请求的情况：

在第6步中，b.com将cookie信息返回给a.com服务器，但是a.com服务器并没有把cookie信息交给浏览器，所以浏览器最终没能写下b.com的cookie信息。

由此可见，为啥header可以设置b.com的cookie，而curl不能设置b.com的cookie在于，header的时候，服务端把cookie信息给了浏览器，而curl的时候，b.com把cookie给了a.com服务器，并没有给到浏览器，所以最终一个设置cookie成功，一个设置cookie失败。