半解TextBox灵异事件背后神秘的深度灵异事件

  1. 云栖社区>
  2. 博客>
  3. 正文

半解TextBox灵异事件背后神秘的深度灵异事件

技术小胖子 2017-11-22 23:02:00 浏览1044
展开阅读全文
TextBox灵异事件:
 
就在前几天,当我来到当下所在的网络时,查看微博粉丝精灵后台时,一件很灵异的事情发生了:TextBox变小了,究竟有多小?我给大伙截一下当前网络下博客园后编辑框:
 
看到了吧,摘要变小了,当时的第一反应是,神马情况?赶紧访问本地的后台,发现正常,难道,黑客入侵了?赶紧再上传复盖一次,情况还是一样。
这让我很纠结,赶紧让另一个有权限的弟兄访问看一下,对方说正常,OH,正常就好,免的自己吓自己,正常就是这个框应该很大,有宽度和高度,由于近两天折腾秋色园深度优化比较忙,因此忽略了一下这个事件。
之后回到老地方上网,也是正常的,更是忘了这问题,今天再度回到这网络,发现还是变小了,刚好有点空,于是开始追寻这问题的根源。
 
为了更简单清晰的说清灵异本质:TextBox灵异事件二度解析:
 
ASPX页面上原始TextBox代码:
<asp:TextBox ID="txtSql" runat="server" Height="298px" TextMode="MultiLine" Width="97%"></asp:TextBox>
 
正常应该生成的html,有style带有宽和高:
<textarea name="txtSql" rows="2" cols="20" id="txtSql" style="height:202px;width:97%;"></textarea>
 
灵异时却生成的html,style不见了:
<textarea name="txtSql" rows="2" cols="20" id="txtSql"></textarea>
 
于是,结果就是如上图的那么小。
 
恰逢秋色园QBlog优化告一小段落,于是腾出点时间出来追踪一下原因:
 
方法一:基础排除法灵异本质
 
1:首先:排除电脑系统环境因素
由于个人带着笔记本两边走,因此基本上排除是电脑的差异引发的问题。
 
2:其次:排除网络差距化因素[这个很神秘]
由于在旧所访问是正常的,因此,我一反应是设置代理访问。
所先寻找到国内代理IP:通过代理“北京”IP访问,问题依旧。
由于服务器在国外,因此找了国外的代理“美国”IP试了访问,问题仍依旧。
 
到这里就很纠结,感觉相当的神秘了,究竟是什么,造成了这么灵异的事件???神秘神秘特神秘!!!
 
方法二:源码追寻法:直击TextBox源码,试图找出问题根源:
 
既然最原始的问题来源于TextBox,看下其源码有啥特别没有先:
 
打开了Reflector,F3搜索TextBox,由于问题是style的宽和高没出来,因此追寻宽和高两个属性。
 
扫了一下TextBox,自身并没有宽和高属性,两个属性继承其基类WebControl的,直接查看Width属性源码:
[DefaultValue(typeof(Unit), ""), WebSysDescription("WebControl_Width"), WebCategory("Layout")]
public virtual Unit Width
{
    get
    {
        if (!this.ControlStyleCreated)
        {
            return Unit.Empty;
        }
        return this.ControlStyle.Width;
    }
    set
    {
        this.ControlStyle.Width = value;
    }
}
 
发现只有!this.ControlStyleCreated时,才会返回Unit.Empty,因此自然的就点进ControlStyleCreated:
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden), Browsable(false), WebSysDescription("WebControl_ControlStyleCreated"), EditorBrowsable(EditorBrowsableState.Advanced)]
public bool ControlStyleCreated
{
    get
    {
        return (this.controlStyle != null);
    }
}
 
只有一行this.controlStyle,很自然又点击controlStyle进去,这一点,一看,我震精了:
 
这么一个大“SB”在我眼前,弄的我都不好意思看下去了。
于是草草扫了几眼,见通篇属性都是用ViewState保存着,似乎与ViewState有着某种联系,于是调整界面相关的ViewState开启又关闭,升级又复盖,结果仍是一样。
 
由于源码过多,又无法调试,加之一堆“特性”和我正负极相坼,于是另寻方法。
 
方法三:网络请求模拟拦截追寻问题:
 
由于最新习惯了原始的抓包比较,于是打开了Fiddler,直接构造一个请求访问本机:
 
这一访问不得了,竟然出现了和服务器一样的灵异事件,文本框返回的style属性不见了。
 
由于之前用浏览器访问是正常的,于是的直接拦截浏览器对本机的请求,发现是正常的有style属性,通过比较,唯一的区别竟然是在“User-Agent”这个属性上。
 
于是,通过多次反复证实,TextBox竟然会和“User-Agent”扯上关系。
而且这关系又很灵异,不是判断User-Agent有没有,而是随意造一个假的User-Agent,也是显示不出来的style属性的。
再经过多次试验证实,其生成的style属性的样式,基本上都有“User-Agent”扯上关系,不仅如此,博客园后台的编辑器也出不来
 
灵异事件到此,终于截到最本质的答案了,前后花了两个小时差不多,当然,灵异的背后,User-Agent和TextBox属性的输出,究竟有着何种深度的关系?时间太晚了,就保留到下次再研究了。
 
灵异事件再次升级:
 
既然发现了“User-Agent”是神秘的主宰,那么,本机发出的请求,究竟发生了什么事情?
由于Fiddler只能拦截从本机发出的请求头,然后这个请求头到达服务器的过程,究竟发生了什么事情?
 
为了追寻这个问题,我在服务器直接设置了把发过来的请求头直接输出,这个一输,吓偶一大跳:
Mozilla/4.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.0.11)
 
本机所有浏览器发出的请求,到达服务器,全是这个请求头!!!!!!
 
竟然还是zh-TW,台湾?这是神马情况?网络被黑客拦截了?这个,地球也太危险了吧!!!
 
留下这未解之迷,该睡了。。。。。。
 
以上文章写于凌晨四点半,这个可以见首发文章地址:http://www.cyqdata.com/cyq1162/article-detail-53227
 
今天正想打10086问下看看有没有头绪,再次访问服务器,查看,晕了,恢复正常了!!!请求头也恢复正常了。
 
难道是我发布的文章被“神秘黑客”发觉了,于是故意恢复的?
如果只是一瞬间的问题,为何持续的时间,从前几天就开始,就到凌晨我发现问题到写完文章,睡一觉就恢复了???
再多的巧合,也解答不了这深度的迷惑,只好留下一些疑问,让过客解答。。。



     本文转自cyq1162 51CTO博客,原文链接:http://blog.51cto.com/cyq1162/753858,如需转载请自行联系原作者



网友评论

登录后评论
0/500
评论
技术小胖子
+ 关注