温故知新,.NET 重定向深度分析

在早期的.NET Framework程序员心里,重定向Redirect其实分为两种:

  • Response.Redirect: Response对象的Redirect方法提供了一种实现客户端重定向的方法

  • Server.Transfer: Server对象的Transfer方法使用服务器执行重定向,并避免HTTP请求

关键区别是发生转移的地方

  

Client Redirect vs Server Redirect

  Response.Redirect方法的默认行为:当前页面暂停执行,并向浏览器发送302响应码和新的跳转URL;

浏览器识别302响应并向跳转URL发起请求, 在network上会呈现两个请求:原始和重定向请求。

Response.Redirect("http://www.news.com",false);   
// 参数2控制当前页执行是否应该终止

  Server.Transfer 方法在服务器转向新的页面请求,并停止当前页面的执行;因为服务器不会将更改通知给客户端浏览器, 在network依旧呈现一个原始请求。

由于页面地址在浏览器中不会更改,因此用户有可能会感觉异样。

Server.Transfer("/default.aspx");
// 由于使用了Web服务器的工作进程,因此Server.Transfer方法的目标URL必须是同一服务器上的虚拟路径,因此您不能使用包含“http”或“https”的地址

 

响应会包含 Location 响应头: A relative (to the request URL) or absolute URL.

可以写入相对地址 或者绝对地址

① 相当于当前页面, 比如我们访问 localhost/swagger 会301 跳转到 localhost/swagger/index.html       

Location: index.html

② /index.html      www.baidu.com 都可以认为是绝对路径。

 

合理选择重定向方式

根据核心差异, 某些情况下需要合理选择重定向方式:

① 性能: 直接的观感是: Response.Redirect相比Server.Transfer多引入了一个HTTP往返,后者可能有更好的性能, 实际上这个从来不是问题。 

② 基本安全性:某些时候对于新页面的请求地址可能要保密 ,Server.Transfer是在服务端请求,不会将请求的详情暴露在浏览器上。

③ 收藏夹:Server.Transfer在服务器上工作,用户虽收到新页面内容,但浏览器中的地址不会更新。因此,用户无法为某些页面添加书签。

④ AJAX用法:Server.Transfer方法缺乏与浏览器的交互,意味着它可能会破坏某些AJAX和/或JavaScript功能。  

⑤ Response.Redirect 能向所有Origin资源发起重定向; 而Server.Transfer() 只能向web服务内资源重定向( 同Origin)。

⑥ 请求次数导致的问题 : Client Redirect是由先向浏览器响应302,在302响应的同时可追加某些信息以利于 后续重定向;

    而Server.Transfer() 对于浏览器而言只有一次请求, 这个差异可能是一个隐藏的分水岭。

我们来分析 单点登录标准协议CAS中发生的 3次302重定向:

  第一,二次发生在SSO、website1不同域之间的重定向,只能使用Client Redirect;

 第三次由 http://www.website1.com?ticket=ST-OOOO-XXXX-OOOO 跳转回同站点的首页www.website1.com 也不能使用 Server.Transfer(),

   因为在跳转后的首页部分资源依赖于302响应时写入的认证Cookie for website1,另外服务端调整,URL地址没有变化,也不妥。

3XX 响应码,傻傻分不清楚

 3XX重定向约定了: 前后请求的Method、Body 是否变化

形态 code 文本解释 对请求Method的操作 典型用法
Permanent redirections↓ 301

永久移动      

GET methods不变;其他Method或许被改成GET        站点改版
  308 永久重定向     Method and Body不变        站点改版,with non-GET links/operations.
Temporary redirections↓ 302 Found      GET methods不变;其他Method或许被改成GET        页面意外不可访问
  303 See other   GET methods不变;其他变成GET (body lost)        在PUT/POST之后重定向, so that refreshing the result page doesn't re-trigger the operation.
  307 临时重定向     Method and Body不变         网页意外不可访问. Better than 302 when non-GET operations are available on the site.
special redirection ↓ 303 Multiple Choice                Not many: the choices are listed in an HTML page in the body. Machine-readable choices are encouraged to be sent as Link headers with rel=alternate.
  304

Not Modified

没有修改   

          Sent for revalidated conditional requests. Indicates that the cached response is still fresh and can be used.

 

总结我们目前肉眼可见的 3xx响应码:

301 “永久移动”

站点改版,比如我们在nginx中强制要求使用 HTTPS:

server {
        listen 80;
        listen [::]:80;
        server_name  www.website1.com;
        return 301 https://$host$request_uri;
    }

302 “对象已移动”或“找到”

  如果附带目标URL,浏览器将重定向行为, 这也是目前口口相传应用最广泛的 重定向

307 Temporary Redirect

  指示所请求的资源已被临时移动到Location标头提供的URL;

307和302之间的唯一区别是307保证在发出重定向请求时,Method 和Body不会更改,当站点上有非GET操作可用时,比302更好。

---

 

服务端常见的 5xx 错误:

  • 502 :(服务网关) nginx作为网关或代理,无法连接到上游服务器。  Nginx runs as a reverse proxy, and is unable to connect to backend services
  • 503: (服务不可用)服务器目前无法使用(由于超载或停机维护)。 通常,这只是暂时状态, 这个例子: https://www.cnblogs.com/JulianHuang/p/13660943.html 上游服务完全下线,网关报: 服务不可用。
  • 504: (网关超时) 服务器作为网关或代理,但是没有及时从上游服务器收到请求。  网关作为代理,请求上游服务超时。

 

 

总结:本文简要分析了Client Redirect,Server Redirect的核心差异、使用场景;

可以按照是否缓存和重定向方法,两个维度去拆分。

  缓存(永久重定向) 不缓存(临时重定向)
转GET 301 302、303
方法保持 308 307

  如果是永久重定向那么浏览器客户端就会缓存此次重定向结果,下次如果有请求则直接从缓存读取,譬如我们切换域名,将所有老域名的流量转入新域名,可以使用永久重定向。

  如果只是临时重定向那么浏览器则不会缓存,譬如我们的服务临时升级,会使用临时重定向。

  方法保持的意思是原请求和重定向的请求是否使用相同的方法,譬如原请求是POST提交一个表单,如果是301重定向的话,重定向的请求会转为GET重新提交,如果是308则会保持原来POST请求不变。

最后给出了HTTP 3XX响应码的标准规范。

https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections

https://www.pmg.com/blog/301-302-303-307-many-redirects 

原文地址:https://www.cnblogs.com/JulianHuang/p/12275874.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


引言 本文从Linux小白的视角, 在CentOS 7.x服务器上搭建一个Nginx-Powered AspNet Core Web准生产应用。 在开始之前,我们还是重温一下部署原理,正如你所常见的.Net Core 部署图: 在Linux上部署.Net Core App最好的方式是在Linux机器
引言: 多线程编程/异步编程非常复杂,有很多概念和工具需要去学习,贴心的.NET提供Task线程包装类和await/async异步编程语法糖简化了异步编程方式。 相信很多开发者都看到如下异步编程实践原则: 遵守以上冷冰冰的②③条的原则,可保证异步程序按照预期状态正常运作;我们在各大编程论坛常看到违背
一. 宏观概念 ASP.NET Core Middleware是在应用程序处理管道pipeline中用于处理请求和操作响应的组件。 每个组件是pipeline 中的一环。 自行决定是否将请求传递给下一个组件 在处理管道的下个组件执行之前和之后执行业务逻辑 二. 特性和行为 ASP.NET Core处
背景 在.Net和C#中运行异步代码相当简单,因为我们有时候需要取消正在进行的异步操作,通过本文,可以掌握 通过CancellationToken取消任务(包括non-cancellable任务)。 Task 表示无返回值的异步操作, 泛型版本Task<TResult>表示有返
HTTP基本认证 在HTTP中,HTTP基本认证(Basic Authentication)是一种允许网页浏览器或其他客户端程序以(用户名:口令) 请求资源的身份验证方式,不要求cookie,session identifier、login page等标记或载体。 - 所有浏览器据支持HTTP基本认
1.Linq 执行多列排序 OrderBy的意义是按照指定顺序排序,连续两次OrderBy,后面一个有可能会打乱前面一个的排序顺序,可能与预期不符。 要实现sql中的order by word,name类似效果; LINQ 有ThenBy可以紧接使用, ThenBy记住原本排序的值,然后再排其他值,
ASP.NET Core 核心特性:开源、跨平台、高性能是其决战JAVA的必胜法宝,最引人关注的跨平台特性 到底是怎么实现? 
 本文分Unix、Windows剖析跨平台内幕,读完让你大呼过瘾。
前导 Asynchronous programming Model(APM)异步编程模型以BeginMethod(...) 和 EndMethod(...)结对出现。 IAsyncResult BeginGetResponse(AsyncCallback callback, object state
引言 最近在公司开发了一个项目,项目部署架构图如下: 思路 如图中文本所述,公司大数据集群不允许直接访问外网,需要一个网关服务器代理请求,本处服务器A就是边缘代理服务器的作用。 通常技术人员最快捷的思路是在服务器A上部署IISʺpplication Request Routing Module组件
作为一枚后端程序狗,项目实践常遇到定时任务的工作,最容易想到的的思路就是利用Windows计划任务/wndows service程序/Crontab程序等主机方法在主机上部署定时任务程序/脚本。 但是很多时候,若使用的是共享主机或者受控主机,这些主机不允许你私自安装exe程序、Windows服务程序
引言 熟悉TPL Dataflow博文的朋友可能记得这是个单体程序,使用TPL Dataflow 处理工作流任务, 在使用Docker部署的过程中, 有一个问题一直无法回避: 在单体程序部署的瞬间(服务不可用)会有少量流量无法处理;更糟糕的情况下,迭代部署的这个版本有问题,上线后无法运作, 更多的流
合格的web后端程序员,除搬砖技能,还必须会给各种web服务器配置Https,本文结合ASP.NET Core部署模型聊一聊启用Https的方式。 温故知新 目前常见的Http请求明文传输,请求可能被篡改,访问的站点可能被伪造。 HTTPS是HTTP加上TLS/SSL协议构建的可进行加密传输、身份认
长话短说 前文《解剖HttpClientFactory,自由扩展HttpMessageHandler》主要讲如何为HttpClientFactory自定义HttpMessageHandler组件, 现在来完成课后的小作业: 将重点日志字段显示到Nlog的LayoutRenderer上。 本文实现一个
引言问题 作为资深老鸟,有事没事,出去面试;找准差距、定位价值。 面试必谈哈希, Q1:什么是哈希? Q2:哈希为什么快? Q3:你是怎么理解哈希算法利用空间换取时间的? Q4:你是怎么解决哈希冲突的? Q5:你有实际用写过哈希算法吗? 知识储备 哈希(也叫散列)是一种查找算法(可用于插入),哈希算
前言 如题,有感于博客园最近多次翻车,感觉像胡子眉毛一把抓, 定位不了生产环境的问题。 抛开流程问题,思考在生产环境中如何做故障排除, 发现博客园里面这方面的文章比较少。 .Net 本身是提供了sos.dll工具帮助我们在生产中故障排除,通过提供有关内部公共语言运行时(CLR)环境的信息,
.NET程序是基于.NET Framework、.NET Core、Mono、【.NET实现】开发和运行的 ,定义以上【.NET实现】的标准规范称为.NET Standard .NET Standard .NET标准是一组API集合,由上层三种【.NET实现】的Basic Class Library
长话短说 上个月公司上线了一个物联网数据科学项目,我主要负责前端接受物联网事件,并提供 参数下载。 webapp 部署在Azure云上,参数使用Azure SQL Server存储。 最近从灰度测试转向全量部署之后,日志时常收到: SQL Session超限报错。 排查 我在Azure上使用的是 S
临近年关,搜狗,360浏览器出现页面无法成功跳转,同域Cookie丢失? 也许是服务端 SameSite惹的祸。
本文揭示由于Chrome低版本内核不识别 SameSite= None, 引发的单点登录故障。
本文聊一聊TraceID的作用和一般组成,衍生出ASP. NETCore 单体和分布式程序中 TraceId 的使用方式
通过给 HttpClint请求的日志增加 TraceId,解锁自定义扩展 HttpClientFacroty 的姿势