ok,这是一个源于404 错误的blog
经典的404 错误想必大家都看烂了
引起这个问题的原因大家都知道,页面没找到嘛。
然而,这个呢,这是我今天遇到的页面?
当然,还是404 嘛,
顿时我心想估计是文件丢失了,就在本机运行下,
幻觉降生了:
在本机IIS调,VS调,
但是诡异的是怎么调怎么都没有这个问题
都顺利的显示了这个页面。
被衰神附体的感觉顿时涌上心头。
费解的没办法。。。。
检查了下语句
里面有个Response.Redirect(Request.Url.ToString());
拿VS 调了下,加断点检测,没问题
将Request.Url.ToString() 读出来,手动访问
没问题,地址顺利访问
在自己机器上发布的版本更是跑的欢的很,顺利的显示了页面
蛋疼,彻底的蛋疼
在折腾了半天无解之后,又仔细的查看了下服务器出错页面的地址:
http://XXX.XXX.XXX/XXX/XXX.aspx
突然觉得不对啊,
应该是Http://XXX.XXX.XXX:8085/XXX/XXX.aspx 啊
摩挲卡,Request.Url.ToString() 没有传端口号?
但是刚在VS 上测了,它能捕获到端口号啊
我试着把本机的IIS 上重新设置了个port
经典的东西出现了
Error 404--Not Found
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.5 404 Not Found
ok,至此,矛头指向了Request.Url.ToString ,它将端口号弄丢失了。
因为自己的IIS 使用的默认的80端口号,就没有引起这个问题,
而VS 的调试,有可能与IIS 的解析方法不同,导致bug 被隐藏
(VS 里的调试里确实可以读到端口号,我也不知道为啥。。。)
找到原因之后,就很好解决了
Response.Redirect 就不引用完整的URL 了 而是写成相对地址
测了一下,ok,乜得问题~
总结
1、相信科学,反对迷信。任何问题都是有原因的。
2、出问题的时候,先从当时的环境分析,而不要最开始就从代码上分析。
3、IIS 与VS 的Asp.net Developerment Server调试的结果很可能不一样,避免这个结果的最好方法,就是在VS上设置使用IIS 调试。
4、IIS 上运行Request.Url.ToString() 会丢失端口号