httpclient

1.关于跨域的说明 1.1 跨域访问测试 测试1: 同服务器测试 说明: 1.浏览器的网址信息: http://manage.jt.com/test.html 2.ajax请求的地址信息: http://manage.jt.com/test.json 发现: 请求协议名称://域名:端口号都相同时,请求可以正常进行. 测试2: 不同的服务器测试 说明:; 1.浏览器的网址信息: http://www.jt.com/test.html 2.ajax请求的地址信息: http://manage.jt.com/test.json 结论: 域名地址不相同时请求不能正常获取响应的结果. 1.2 同源策略介绍 说明: 浏览器在解析ajax时 ,如果发现 请求的协议名称://请求的域名:请求的端口号 与网址的地址都相同的时满足同源策略的规定,浏览器可以正确的解析返回值.该访问称之为 同域访问 .该策略叫做 同源策略. 但是如果 违反了同源策略中的任意一条 ,则叫做 跨域访问 .浏览器出于安全性的考虑.不予解析返回值(请求正常的被处理,但是接收不到返回值). 概括: 浏览器解析ajax时,由于请求违反了同源策略则称之为跨域请求. 例子: http://localhost:8091/xxx.html http://manage.jt.com/xx.html 不可以通讯 1.3 JSONP实现跨域 1

　　接口自动化测试框架的部分，之前的章节都已经介绍完毕了。按照这个思路基本就可以完成一套接口自动化测试方面的框架，并开始测试了。 　　作为一个老测试，今天主要想说一些感想。 　　一、源码的问题 　　其实，我向大家介绍的这一套测试，并没有一个固定的源码。它其实源自网上很多不同大佬的源码，在使用过程中不断的经过自己的“加工提炼”，使得更符合自己的工作环境而已。因此，源码这个东西，说实话，我自己都没整理好，只是在不断的用不断的改。 我写这些文章的目的，其实只是提供一些思路。能够给一些愿意进行自动化测试/工具开发的童鞋提供某些参考，已经是莫大的荣幸。 　　二、基础自动化测试环境的搭建 　　作为核心代码的部分，在之前的章节中已经能够基本运行起来。但是，真正到工作中使用，还需要构建持续集成等环境。关于这方面，之后有时间再推出相关文章。 　　接口自动化测试的内容就结束了。 　　测试工具是其次，关键是测试思维。老测试在这方面其实很受定势思维的影响，年轻的童鞋们加油哈。 　　（原本有好些感慨，一到书面又写不出来了。囧！） 　　 来源： oschina 链接： https://my.oschina.net/u/4343285/blog/4524855

前言 近期由于需要进行分布式链路跟踪系统的技术选型，所以一直在研究链路跟踪相关的框架。作为能在.Net Core中使用的APM，SkyWalking自然成为了首选。 SkyAPM-dotnet 是SkyWalking在.Net Core端的探针实现，其主要的收集日志的手段就是基于DiagnosticSource来进行诊断跟踪的。不得不说SkyAPM-dotnet的设计还是非常优秀的，它本身定义了一套非常规范的标准，而且提供了非常良好的扩展性，虽然框架本身可支持的采集端有限，但是基于这套标准扩展起来还是非常方便的。 概念介绍 关于DiagnosticSource它本身是一个基于发布订阅模式的工作模式，由于它本身的实现方式是异步的，所以不仅仅可以把它用到日志上，还可以用它实现异步操作，或者用它简化实现发布订阅的功能。DiagnosticSource本身是一个抽象类，我们最常用到的是它的子类DiagnosticListener，通过DiagnosticSource的Write方法实现发布一条有具体名称的消息，然后通过IObserver去订阅消息。DiagnosticListener可以实现不同的实例，每个实例可以有自己的名称，每个实例还可以发布不同名称的消息，好比一个在写代码的时候我们可以定义多个程序集，一个程序集下面可以包含多个命名空间。 使用方式

前言 本章结束之后，这个abp vnext系列算是初步完结了，基础的组件都已经接入了。如果各位还需要其它的组件的话，可以自己按需要进行接入使用。其实这个只是一个基础的框架，可以自己根据需要进行变通的。比如：如果没有太多需求且更熟悉三层的同学可以把application和application.contract去掉就是一个三层架构了。基础是基础，用好还是要看各位对业务的理解是否够深入才能发挥好框架的作用。 对于各个框架的使用，建议是：先使用起来，然后熟悉它，再然后改造它。并不是按照别人的标准一味的照抄，每一个框架都会有相应的痛点。。因此在使用的时候是要根据项目与团队来进行评估是否适用，若不适用的时候，如何去调整。这个不仅仅是架构师要考虑的事情。 个人经验（仅作参考）：建议每一位有想法开发人员都要保持自己的独立思考能力，无论是针对业务还是技术。但是前期是先积累技术自己验证，多在群里 友好 交流，不说教只分析。先从大量的文章和博客中获取知识，理出自己需要的进行沉淀。到了一定地步（这个一定地步只能看感觉，这种感觉会非常的明显，需要自己保持反思，相当于比较大的坎，越过之后就是新的开始的这种）之后，再配合一些好的收费课程和书籍去深入和系统化的学习。比如：曾经我就在群里看到一个大佬的分享然后开始入门算法，当时他分享的是hash算法，后面我有把它很白话的用场景分享给前端朋友

Web能够打下天下，最重要的功臣就是HTTP；HTTP能够建功立业，最重要的原因就是它的简单。 微软在.NET Framework 4.5中为大家带来了System.Net.Http.HttpClient，既然叫HttpClient，我想应该迎合了HTTP简单的特性，应该会比HttpWebRequest更简单。 在之前的博文“ jQuery能做到，PHP能做到，C#也能做到 ”中也的确发现用HttpClient发起HTTP POST请求并传递url query string参数，比用HttpWebRequest更简单。于是打算把基于HttpWebRequest的实现改为基于HttpClient的实现。 基于HttpWebRequest的实现中有设置UserAgent的代码： var webRequest = WebRequest.Create(url) as HttpWebRequest; webRequest.UserAgent = " CNBlogs " ; 本来以为HttpClient也有同样的UserAgent属性，于是想这样写： var httpClient = new HttpClient(); httpClient.UserAgent = " CNBlogs " ; // 错误的代码 结果发现HttpClient根本没有UserAgent这个属性。 于是，找啊找