<1>
 
一个Option请求引发的深度解析
 
在当前项目中，前端通过POST方式访问后端的REST接口时，发现两条请求记录，一条请求的Request Method为Options，另一条请求的Reuest Method为Post。想要解决这个疑惑还得从以下3个概念说起。
 
Http Options Method
 
RFC2616标准（现行的HTTP/1.1）中如下描述：
 
 
简而言之，OPTIONS请求方法的主要用途有两个：
 
1、获取服务器支持的HTTP请求方法；
 
2、用来检查服务器的性能。
 
 
 
CORS(跨域资源共享)
 
CORS是一种网络浏览器的技术规范，它为Web服务器定义了一种方式，允许网页从不同的域访问其资源。而这种访问是被同源策略所禁止的。CORS系统定义了一种浏览器和服务器交互的方式来确定是否允许跨域请求。 
 
使用CORS的方式非常简单，但是需要同时对前端和服务器端做相应处理。
 
1、  前端
 
客户端使用XmlHttpRequest发起Ajax请求，当前绝大部分浏览器已经支持CORS方式，且主流浏览器均提供了对跨域资源共享的支持。
 
2、  服务器端
 
如果服务器端未做任何配置，则前端发起Ajax请求后，会得到CORS Access Deny，即跨域访问被拒绝。
 
对于C#做如下配置可允许资源的跨域访问： 
 
<system.webServer>
 ...
 <httpProtocol>
 <customHeaders>
 <add name="Access-Control-Allow-Origin" value="*" />
 <add name="Access-Control-Allow-Headers" value="Origin, X-Requested-With, Content-Type" />
 <add name="Access-Control-Allow-Methods" value="PUT,GET,POST,DELETE,OPTIONS"/>
 </customHeaders>
 </httpProtocol>
 </system.webServer>
 
对于nodejs做如下配置可允许资源的跨域访问： 
 
//设置CORS跨域访问
 app.all('*', function (req, res, next) {
 res.header("Access-Control-Allow-Origin", "*");
 res.header("Access-Control-Allow-Headers", "X-Requested-With, accept, origin, content-type");
 res.header("Access-Control-Allow-Methods", "PUT,POST,GET,DELETE,OPTIONS");
 res.header("X-Powered-By", ' 3.2.1')
 res.header("Content-Type", "application/json;charset=utf-8");
 next();
 });
 
Access-Control-Allow-Origin:*表示允许任何域发起请求，如果只允许特定的域访问，则设置Access-Control-Allow-Origin:xxx为具体域名即可。
 
 
 
Preflighted Requests(预检请求)
 
Preflighted Requests是CORS中一种透明服务器验证机制。预检请求首先需要向另外一个域名的资源发送一个 HTTP OPTIONS 请求头，其目的就是为了判断实际发送的请求是否是安全的。
 
下面的2种情况需要进行预检：
 
1、  简单请求，比如使用Content-Type 为 application/xml 或 text/xml 的 POST 请求；
 
2、中设置自定义头，比如 X-JSON、X-MENGXIANHUI 等。
 
 
 
 
了解完这3个概念，其实答案已经了然了。
 
 
 
参考：
 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
 
http://blog.csdn.net/hfahe/article/details/7730944
 
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
 
<2>
 
HTTP请求方法并不是只有GET和POST，只是最常用的。据RFC2616标准（现行的HTTP/1.1）得知，通常有以下8种方法：OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE和CONNECT。
 
HTTP请求方法并不是只有GET和POST，只是最常用的。据RFC2616标准（现行的HTTP/1.1）得知，通常有以下8种方法：OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE和CONNECT。

  
 
官方定义
 


 OPTIONS方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。


 该请求方法的响应不能缓存。


 如果这个OPTIONS请求包含一个正文（有Content-Length或Transfer-Encoding存在），则必须有Content-Type来指定媒体类型。虽然规范里没有定义这种正文的用法，但是HTTP将来的扩展可能会用它来查询服务器上更详细的信息。不支持该扩展的服务器可以忽略该请求正文。


 如果该URI是一个星号（“*”），OPTIONS请求将试图应用于服务器，而不是某个指定资源。由于服务器的通信选项通常依赖于资源，所以此“*”请求只能作为“ping”或者“no-op”方法；或者用来测试服务器的性能。例如，用来测试HTTP/1.1代理。


 如果该URI不是星号，则只能用来获取该资源通信中可用的选项。


 得到的200响应应该包含一个头域，指明服务器实现的和适用于该资源的可选特征（如：Allow），可能还包括该规范尚未定义的扩展。如果有响应正文，则应包含关于通信选项的信息。本规范没有定义该正文格式，但可能在HTTO将来的扩展中定义。可以利用内容协商来选择合适的响应格式。如果没有响应正文，响应必须包含Content-Length，并且值为“0”。


 请求头的Max-Forwards用来请求特定代理。当代理收到一个允许URI转发的OPTIONS请求，则检查Max-Forwards。如果Max-Forwards值为0，则不能转发该消息；相反，代理会将自己的通信选项去响应。如果Max-Forwards是正整数，代理转发请求的时候会将该值减1。如果请求中没有Max-Forwards，转发的请求也不会有。
 
 
 
 
 
 
 
简而言之
 


 OPTIONS请求方法的主要用途有两个：


 1、获取服务器支持的HTTP请求方法；也是黑客经常使用的方法。


 2、用来检查服务器的性能。例如：AJAX进行跨域请求时的预检，需要向另外一个域名的资源发送一个HTTP OPTIONS请求头，用以判断实际发送的请求是否安全。
  
 
The DELETE Method
 
HTTP提供了一个与PUT方法对应的DELETE方法。一个DELETE请求将需要从Web服务器删除的内容指定为请求行中的资源部分。
 DELETE方法唯一有趣的地方在于当你接收了一个标识为200 OK的响应的时候，那并不意味着指定的资源已经被删除了。那仅仅说明服务器接收到了删除资源的命令。这一例外允许了出于安全考虑的人为的干预
 
转自：http://blog.csdn.net/leikezhu1981/article/details/7402272
 
<3>
 
出于安全考虑，并不是所有域名访问后端服务都可以。其实在正式跨域之前，浏览器会根据需要发起一次预检（也就是option请求），用来让服务端返回允许的方法（如get、post），被跨域访问的Origin（来源或者域），还有是否需要Credentials(认证信息)等。那么浏览器在什么情况下能预检呢？
 
二、两种请求方式
 
    浏览器将CORS请求分为两类：简单请求（simple request）和非简单请求（not-simple-request）,简单请求浏览器不会预检，而非简单请求会预检。这两种方式怎么区分？
 
同时满足下列三大条件，就属于简单请求，否则属于非简单请求
 
1.请求方式只能是：GET、POST、HEAD
 
2.HTTP请求头限制这几种字段：Accept、Accept-Language、Content-Language、Content-Type、Last-Event-ID
 
3.Content-type只能取：application/x-www-form-urlencoded、multipart/form-data、text/plain
 
对于简单请求，浏览器直接请求，会在请求头信息中，增加一个origin字段，来说明本次请求来自哪个源（协议+域名+端口）。服务器根据这个值，来决定是否同意该请求，服务器返回的响应会多几个头信息字段，如图所示：上面的头信息中，三个与CORS请求相关，都是以Access-Control-开头。
 
1.Access-Control-Allow-Origin：该字段是必须的，* 表示接受任意域名的请求，还可以指定域名
 
2.Access-Control-Allow-Credentials：该字段可选，是个布尔值，表示是否可以携带cookie，（注意：如果Access-Control-Allow-Origin字段设置*，此字段设为true无效）
 
3.Access-Control-Allow-Headers：该字段可选，里面可以获取Cache-Control、Content-Type、Expires等，如果想要拿到其他字段，就可以在这个字段中指定。比如图中指定的GUAZISSO
 
非简单请求是对那种对服务器有特殊要求的请求，比如请求方式是PUT或者DELETE，或者Content-Type字段类型是application/json。都会在正式通信之前，增加一次HTTP请求，称之为预检。浏览器会先询问服务器，当前网页所在域名是否在服务器的许可名单之中，服务器允许之后，浏览器会发出正式的XMLHttpRequest请求，否则会报错。（备注：之前碰到预检请求后端没有通过，就不会发正式请求，然后找了好久原因，原来后端给忘了设置...）Java后端实现拦截器，排除Options
 
 
JAVA代码片段
 
就Content-Type为application/json为例：对比两张图片，一次预检请求，一 次正式请求：
 
 
预检请求
 
 
正式请求
 
很明显，请求头中预检请求不会携带cookie，正式请求会携带cookie和参数。跟普通请求一样，响应头也会增加同样字段。
 
一旦服务器通过了“预检”请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样。
 


  

 
目录
 
1、Ceres简介
2、常用通用参数
3、与优化算法相关的参数
3.1、优化方法无关参数
3.2、TRUST_REGION
3.3、LINE_SEARCH
  
4、与线性求解器有关的参数

 
1、Ceres简介
 
Ceres是一个非常优秀的非线性优化库（谷歌出品）。能完成很复杂的优化功能，选项也非常的多，本篇博客就来梳理下这些选项。Ceres的参数主要有三类，一类通用参数，比如迭代次数什么的；第二类是和优化算法的参数；第三类是和线性求解器（在信任域算法中被使用）有关的参数。
 我在调Ceres Solver的优化的参数时，我首先会调最大迭代次数，然后换优化算法，调优化算法的参数，最后再调线性求解器的参数。
 并不是所有的参数我都列出来了，我只列出常用的参数。
 参考：solver-options。
 
2、常用通用参数
 
 
bool Solver::Options::IsValid(string *error) const
 检查options是否合法，不合法的话返回false，并将错误信息存到error里面。
 
 
int Solver::Options::max_num_iterations
 默认值：50
 最大迭代次数。
 
 
double Solver::Options::max_solver_time_in_seconds
 默认值：1e6
 最长运行时间，单位为秒。
 
 
int Solver::Options::num_threads
 默认值：1
 Ceres用于评估Jacobian的线程数，越多优化速度越快。
 
 
DenseLinearAlgebraLibrary Solver::Options::dense_linear_algebra_library_type
 默认值：EIGEN
 Ceres支持使用多个密集线性代数库进行稠密矩阵分解。 目前可选的为EIGEN和LAPACK。 EIGEN始终可用；LAPACK指的是BLAS + LAPACK库，可能有也可能没有（得看编译Ceres库时有没有加入BLAS + LAPACK的支持）。
 此设置会影响DENSE_QR，DENSE_NORMAL_CHOLESKY和DENSE_SCHUR求解器。 对于小到中等大小的求解器（这里的大小应该是指运算量，也就是问题规模的大小），EIGEN是一个很好的选择，但对于大问题，LAPACK + BLAS实现可以在性能上优势很大。
 
 
SparseLinearAlgebraLibrary Solver::Options::sparse_linear_algebra_library_type
 默认值：SUITE_SPARSE > CX_SPARSE > EIGEN_SPARSE > NO_SPARSE
 Ceres支持使用三个稀疏线性代数库SuiteSparse、CXSparse、EIGEN_SPARSE ，NO_SPARSE意味着不应使用稀疏线性求解器。
 SuiteSparse是一个非常复杂的稀疏线性代数库（就是一群非常牛*的人写的），性能最好，推荐使用。如果SuiteSparse不可用（编译Ceres的时候没有加入SuiteSparse支持），请考虑使用CXSparse，这是一个更小，更容易编译的库。但是，它在大问题上的性能与SuiteSparse的性能相差巨大。也可以使用Eigen中稀疏线性代数库。目前，这个库的表现是三个中最差的。说不定在不久的将来性能会有改善。
 
 
int Solver::Options::num_linear_solver_threads
 默认值：-1
 这是一个废弃的选项，将在1.15中删除。
 
 
LoggingType Solver::Options::logging_type
 默认值：PER_MINIMIZER_ITERATION
 每次迭代都打印信息，另一个可选的为SILENT。
 
 
bool Solver::Options::minimizer_progress_to_stdout
 默认值：false
 默认情况下，Minimizer（优化器）进度会记录到stderr，具体取决于vlog级别。 如果此标志设置为true，并且Solver::Option:: logging_type不是SILENT，则日志记录输出将发送到stdout（在终端打印出信息）。
 对于TRUST_REGION_MINIMIZER，进度显示如下:
 
 
iter      cost      cost_change  |gradient|   |step|    tr_ratio  tr_radius  ls_iter  iter_time  total_time
   0  4.185660e+06    0.00e+00    1.09e+08   0.00e+00   0.00e+00  1.00e+04       0    7.59e-02    3.37e-01
   1  1.062590e+05    4.08e+06    8.99e+06   5.36e+02   9.82e-01  3.00e+04       1    1.65e-01    5.03e-01
   2  4.992817e+04    5.63e+04    8.32e+06   3.19e+02   6.52e-01  3.09e+04       1    1.45e-01    6.48e-01
 
1. cost 是目标函数的值。
2. cost_change 是目标函数值的变化。
3. |gradient| 是梯度的最大范数。
4. |step| 是参数向量的变化。
5. tr_ratio是目标函数值的实际变化与信赖域模型值的变化之比。
6. tr_radius是信任区域半径的大小。
7. ls_iter是用于计算信任区域步骤的线性求解器迭代次数。
8. total_time是所用的总时间。
 
对于LINE_SEARCH_MINIMIZER，进度显示如下:
 
0: f: 2.317806e+05 d: 0.00e+00 g: 3.19e-01 h: 0.00e+00 s: 0.00e+00 e:  0 it: 2.98e-02 tt: 8.50e-02
1: f: 2.312019e+05 d: 5.79e+02 g: 3.18e-01 h: 2.41e+01 s: 1.00e+00 e:  1 it: 4.54e-02 tt: 1.31e-01
2: f: 2.300462e+05 d: 1.16e+03 g: 3.17e-01 h: 4.90e+01 s: 2.54e-03 e:  1 it: 4.96e-02 tt: 1.81e-01
 
1. f是目标函数的值。
2. d是目标函数的值的变化。
3. g是梯度的最大范数。
4. h是参数向量的变化。
5. s是线搜索计算的最佳步长。
6. it是当前迭代所花费的时间。
7. tt是最小化器所用的总时间。
 
 
bool Solver::Options::check_gradients
 默认值：false
 检查由具有有限差分的每个残差块计算的所有雅可比行列式，比较结果，如果它们大不相同，则优化失败。如果设置为true的花比较耗费性能，一般保持默认。
 
 
double Solver::Options::gradient_check_relative_precision
 默认值: 1e8
 在gradient checker中检查的精度。 如果雅可比行列式中的元素之间的相对差异超过此数字，则dump该cost term的雅可比行列式。
 
 
vector Solver::Options::callbacks
 在Minimizer的每次迭代结束时执行的回调。 它们按照在此vector中指定的顺序执行。 默认情况下，参数仅在优化结束时更新。 如果希望在执行回调时访问更新的参数，则将Solver::Options::update_state_every_iteration需要设置为true。
 
 
bool Solver::Options::update_state_every_iteration
 默认值：false
 如果为true，则在每个迭代结束时更新参数，否则在优化终止时才更新参数。更多细节请参考链接。
 
 
3、与优化算法相关的参数
 
在Ceres中，求解优化问题有两类方法：信任域（TRUST_REGION）和线性搜索（LINE_SEARCH，尚不支持边界约束），和它们相关的主要的参数如下图所示（小写的是选项）：
 

 上面的参数应该就是本篇文档中重要的几个参数。
 
3.1、优化方法无关参数
 
 
MinimizerType Solver::Options::minimizer_type
 默认值：TRUST_REGION
 可选的为LINE_SEARCH和TRUST_REGION，这是非线性优化的两类算法。参考：Trust Region Methods 、 Line Search Methods。
 
 
double Solver::Options::gradient_tolerance
 默认值：1e-10
 求解器会在满足
 $$\Vert x-\Pi ⊞(x,-g(x)){\Vert }_{\infty }<=\text{gradient\_tolerance}$$
 时停止求解。其中||⋅||∞是指最大范数，Π是对边界约束的投影，⊞是与参数矢量相关的整体局部参数化的加法运算。
 
 
3.2、TRUST_REGION
 
 
double Solver::Options::function_tolerance
 默认值：1e-6
 求解器会在满足：
 $$\frac{|\Delta \text{cost}|}{\text{cost}}<=\text{function\_tolerance}$$
 时停止求解，其中Δcost是Levenberg-Marquardt方法中当前迭代中目标函数值（也就是损失函数）的变化。上面的公式可以这样理解，Δcost/cost非常小了，就说明cost基本没啥变化，就认为已经得到一个解了，故停止优化。
 
 
TrustRegionStrategyType Solver::Options::trust_region_strategy_type
 默认值：LEVENBERG_MARQUARDT
 可选的为LEVENBERG_MARQUARDT和DOGLEG。更多细节请参考： Levenberg-Marquardt 和 Dogleg。
 
 
DoglegType Solver::Options::dogleg_type
 默认值：TRADITIONAL_DOGLEG
 可选的为TRADITIONAL_DOGLEG和SUBSPACE_DOGLEG。更多细节请参考： Dogleg。
 
 
bool Solver::Options::use_nonmonotonic_steps
 默认值：false
 更多细节请参考原文档。
 
 
double Solver::Options::initial_trust_region_radius
 默认值：1e4
 初始信任区域的大小。 当使用LEVENBERG_MARQUARDT策略时，该数字的倒数是初始正则化参数。
 
 
double Solver::Options::max_trust_region_radius
 默认值：1e16
 信任区域半径最大值。
 
 
double Solver::Options::min_trust_region_radius
 默认值：1e-32
 信任区域的最小值。当信任区域小于此值，会停止优化。
 
 
double Solver::Options::min_relative_decrease
 默认值：1e-3
 信任域步长(trust region step)相对减少的最小值。
 
 
double Solver::Options::min_lm_diagonal
 默认值：1e6
 LEVENBERG MARQUARDT算法使用对角矩阵来规范（regularize）信任域步长。 这是该对角矩阵的值的下限。
 
 
double Solver::Options::max_lm_diagonal
 默认值：1e32
 LEVENBERG MARQUARDT算法使用对角矩阵来规范（regularize）信任域步长。这是该对角矩阵的值的上限。
 
 
int Solver::Options::max_num_consecutive_invalid_steps
 默认值：5
 信任区域策略返回的步骤有时可能在数值上无效，通常是因为条件问题。 优化器可以继续尝试使用较小的信任区域/更好的条件问题来解决，而不是崩溃或停止优化。 此参数设置最小化器停止优化之前的连续重试次数。
 
 
3.3、LINE_SEARCH
 
 
LineSearchDirectionType Solver::Options::line_search_direction_type
 默认值：LBFGS
 可选的为STEEPEST_DESCENT、NONLINEAR_CONJUGATE_GRADIENT、BFGS和LBFGS，都属于LINE_SEARCH类的算法。
 
 
LineSearchType Solver::Options::line_search_type
 默认值：WOLFE
 选择是ARMIJO和WOLFE（强WOLFE条件）。 为了保证BFGS和LBFGS线搜索方向算法的基本假设得到满足，应使用WOLFE线性搜索。
 
 
int Solver::Options::max_lbfgs_rank
 默认值：20
 L-BFGS的Hessian矩阵是对Hessian矩阵的逆的低秩近似。 近似的秩的大小与近似算法的空间和时间复杂度线性相关。 秩越高，近似的质量越好。 然而，由于以下两种原因，质量的提高受到限制。
 ～The method only uses secant information and not actual derivatives.
 ～The Hessian approximation is constrained to be positive definite.
 因此，将该秩增加到一个特别大的数字将大量将花费时间和空间而不会相应地提高求解的质量。不同的问题，可能最佳的秩也不同。
 
 
bool Solver::Options::use_approximate_eigenvalue_bfgs_scaling
 默认值：false
 更多细节请参考原文档。
 
 
LineSearchIterpolationType Solver::Options::line_search_interpolation_type
 默认值：CUBIC
 用于近似目标函数的多项式的次数。 可选的为BISECTION，QUADRATIC和CUBIC。
 
 
double Solver::Options::min_line_search_step_size
 线性搜索将在满足
 $$\Vert \Delta x_k{\Vert }_{\infty }<\text{min\_line\_search\_step\_size}$$
 时停止搜索。其中||⋅||∞是指无穷范数，Δxk是第k次迭代时参数值的step的变化量。这是线性线性搜索算法的一个终止条件。
 
 
double Solver::Options::line_search_sufficient_function_decrease
 默认值：1e-4
 完全解决线搜索问题在计算上是令人望而却步的。 幸运的是，基于行搜索的优化算法仍然可以保证收敛，如果不是精确的解决方案，行搜索算法返回一个充分降低目标函数值(cost)的解。 更准确地说，寻找步长s.t.
 $$f(\text{step\_size})\le f(0)+\text{sufficient\_decrease}\ast [f^{\prime }(0)\ast \text{step\_size}]$$
 上面的就是Armijo条件。
 
 
double Solver::Options::max_line_search_step_contraction
 默认值: 1e-3
 在线性搜索算法的每次迭代中，
 $$\text{new\_step\_size}>=\text{max\_line\_search\_step\_contraction}\ast \text{step\_size}$$
 根据定义，满足约束：
 $$0<\text{max\_step\_contraction}<\text{min\_step\_contraction}<1$$
 
 
double Solver::Options::min_line_search_step_contraction
 默认值：0.6
 在线性搜索算法的每次迭代中，
 $$\text{new\_step\_size}<=\text{min\_line\_search\_step\_contraction}\ast \text{step\_size}$$
 根据定义，满足约束：
 $$0<\text{max\_step\_contraction}<\text{min\_step\_contraction}<1$$
 
 
int Solver::Options::max_num_line_search_step_size_iterations
 默认值：20
 每次线搜索期间的最大试验步长迭代次数，如果在此次试验次数内无法找到满足搜索条件的步长（step size），则线性搜索将停止。
 由于这是一个“人为”约束，如果正在使用WOLFE线性搜索，并且在当前搜索期间找到了满足Armijo条件的的点（in < = max_num_line_search_step_size_iterations）。 然后，具有满足Armijo条件的最低函数值的步长将作为新的有效步长返回，即使它不满足强Wolfe条件。可防止优化器在次优解处提前终止。
 
 
int Solver::Options::max_num_line_search_direction_restarts
 默认值：5
 线性搜索方向算法的最大重启次数，超过此数值时，求解就停止了。 当当前算法未能产生新的下降方向时，线性搜索方向算法会重新开始。
 
 
double Solver::Options::line_search_sufficient_curvature_decrease
 默认值：0.9
 更多细节请参考原文档。
 
 
double Solver::Options::max_line_search_step_expansion
 默认值：10.0
 和Wolfe线性搜索相关。更多细节请参考原文档。
 
 
4、与线性求解器有关的参数
 
 
double Solver::Options::parameter_tolerance
 默认值：1e-8
 求解器会在
 $$\Vert x-\Pi ⊞(x,-g(x)){\Vert }_{\infty }<=\text{gradient\_tolerance}$$
 其中Δx是当前迭代中线性求解器（Linear Solver）计算的步长。
 
 
LinearSolverType Solver::Options::linear_solver_type
 默认值：SPARSE_NORMAL_CHOLESKY / DENSE_QR
 线性求解器的类型，用于计算Levenberg-Marquardt算法每次迭代中线性最小二乘问题的解。 如果编译Ceres时加入了SuiteSparse或CXSparse或Eigen的稀疏Cholesky分解选项，则默认为SPARSE_NORMAL_CHOLESKY，否则为DENSE_QR。
 
 
PreconditionerType Solver::Options::preconditioner_type
 默认值：JACOBI
 迭代线性求解器使用的预处理器(Preconditioner)。 默认是块Jacobi预处理器。 有效值是IDENTITY，JACOBI，SCHUR_JACOBI，CLUSTER_JACOBI和CLUSTER_TRIDIAGONAL（复杂程度依次递增）。 更多细节请参考Preconditioner。
 
 
DenseLinearAlgebraLibrary Solver::Options::dense_linear_algebra_library_type
 默认值：EIGEN
 
 
shared_ptr Solver::Options::linear_solver_ordering
 默认值：NULL
 更多细节请参考原文档。
 
 
还有很多关于求解器的参数，用的少，我懒得列了。

【以下是转载内容】
 
 码字很辛苦，转载请注明来自tuy博客的《XMLHttpRequest 跨域时产生了 OPTIONS 请求》
 
一：前言
 
对于跨域请求，一直没有采用jsonp方式，原因如下
 
1.jsonp只支持get请求而不支持post请求,如果想传给后台一个json格式的数据,浏览器会返回一个415的状态码，告诉我们请求格式不正确，这让传输大规模数据变得繁琐。
 
2.无法准确定位和调试请求异常情况
 
3.存在安全性问题(可能是我的技术盲点，因为看到很多大公司都用jsonp技术)
 
考虑到以上问题，并且跨域资源共享标准 允许XMLHttpRequest 或 Fetch 发起跨域 HTTP 请求，前后端约定数据请求一律采用XMLHttpRequest，通过后台设置响应报文头 Header set Access-Control-Allow-Origin *，即可实现跨域访问。为了防止XSS攻击， 我们又进行域名限制，比如 Access-Control-Allow-Origin: http://www.xudihui.com
 
二：正文
 
用了好几个项目下来，一直没出问题。今天维护老项目时，发现请求新接口并不能准确拿到业务数据，而是触发了一个OPTIONS请求,请求头如下：
 
 
1
 
2
 
3
 
4
 
5
 
6
 
7
 
8
 
9
 
10
 
11
 
 
OPTIONS http://activity.96225.com/win_smk_activity/baseUser/getUserIdByToken.ext HTTP/1.1
 
Host: activity.96225.com
 
Connection: keep-alive
 
Access-Control-Request-Method: POST
 
Origin: http://192.168.2.176:4000
 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36
 
Access-Control-Request-Headers: appid
 
Accept: */*
 
Referer: http://192.168.2.176:4000/
 
Accept-Encoding: gzip, deflate, sdch
 
Accept-Language: zh-CN,zh;q=0.8
 
 
 
从请求头来看，OPTIONS请求前端代码并没有发起，仔细查看请求头字段：
 
字段 Access-Control-Request-Method 告知服务器，实际请求将使用 POST 方法；
 
字段 Access-Control-Request-Headers 告知服务器，实际请求将携带一个自定义请求首部字段：appid，appid是用来告知服务端业务逻辑使用，ajax被封装之后，appid携带在该项目所有请求头中；
 
字段 Host 告诉我们服务器主机名；
 
字段 Referer 显示了本地开发地址，Host和Referer是典型的跨域请求。 
 
带着疑问去了解OPTIONS请求，首先查看了ajax方法，除了xhr对象序列和增加了一个请求头appId之外，并没有其它逻辑，代码如下：
 
 
1
 
2
 
3
 
4
 
5
 
6
 
7
 
8
 
9
 
10
 
11
 
12
 
13
 
14
 
15
 
16
 
17
 
18
 
19
 
20
 
21
 
22
 
23
 
24
 
25
 
26
 
27
 
28
 
29
 
30
 
31
 
32
 
33
 
34
 
35
 
36
 
37
 
38
 
39
 
40
 
41
 
42
 
43
 
44
 
45
 
46
 
47
 
48
 
49
 
50
 
51
 
52
 
53
 
54
 
55
 
56
 
57
 
58
 
59
 
60
 
61
 
62
 
 
var ajax_ = function(obj) {
 
        obj = obj || {};
 
        obj.type = (obj.type || 'GET').toUpperCase();
 
        obj.dataType = obj.dataType || 'json';
 
        obj.timeout = obj.timeout || 20000;
 
        var params = formatParams(obj.data); //参数格式化
 
        var xhrTimeout;//前端定时放弃
 
        //step1:兼容性创建对象
 
        if (window.XMLHttpRequest) {
 
            var xhr = new XMLHttpRequest();
 
        } else {
 
            var xhr = new ActiveXObject('Microsoft.XMLHTTP');
 
        }
 
        if(AJAX_ == 0){
 
          UI.showIndicator();
 
        }
 
        AJAX_++;
 
        //step4: 接收
 
        xhr.onreadystatechange = function() {
 
            if (xhr.readyState == 4) {
 
                 AJAX_--;
 
                if(AJAX_== 0){
 
                  UI.hideIndicator();
 
                }
 
                try{
 
                    if (xhr.status >= 200 && xhr.status < 300) {
 
                        obj.success && obj.success(xhr.responseText, xhr.responseXML);
 
                    } else {
 
                        obj.error && obj.error(xhr.status);
 
                    }                     
 
                }catch(e){} 
 
            }
 
        }
 
        //step2 step3:连接 和 发送
 
        if (obj.type == 'GET') {
 
            xhr.open('GET', obj.url + '?' + params, true);
 
            xhr.setRequestHeader('appId', $APPID);
 
            xhr.send(null);
 
        } else if (obj.type == 'POST') {
 
            xhr.open('POST', obj.url, true);
 
            //设置请求头，以表单形式提交数据
 
            xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
 
            xhr.setRequestHeader('appId', $APPID);
 
            xhr.send(params);
 
        }
 
         // 超时,默认20秒，直接设置timeout属性：https://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/#handler-xhr-ontimeout
 
         xhr.timeout = obj.timeout;
 
         xhr.ontimeout = function(){
 
            UI.toast('请检查网络连接是否正常',2000,'exception');
 
         }
 
 
 
        //辅助函数，格式化参数
 
        function formatParams(data) {
 
            var arr = [];
 
            for (var name in data) {
 
                arr.push(encodeURIComponent(name) + "=" + encodeURIComponent(data[name]));
 
            }
 
            //设置随机数，防止缓存
 
            arr.push("t=" + Math.random());
 
            return arr.join("&");
 
        }
 
    }
 
通过stackoverflow的这篇文章，得知我遇到的OPTIONS是浏览器发起的'preflight'请求，征求服务器是否允许该实际请求。"预检请求“的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。但是我其它项目中并没有产生OPTIONS请求，它是从哪里来的呢，继续查看触发条件，当满足以下条件时，浏览器主动触发OPTIONS请求：
 
1、使用了下面任一 HTTP 方法：
 
  – PUT
 
  – DELETE
 
  – CONNECT
 
  – OPTIONS
 
  – TRACE
 
  – PATCH
 
2、人为设置了对 CORS 安全的首部字段集合之外的其他首部字段。该集合为：
 
  – Accept
 
  – Accept-Language
 
  – Content-Language
 
  – Content-Type (but note the additional requirements below)
 
  – DPR
 
  – Downlink
 
  – Save-Data
 
  – Viewport-Width
 
  – Width
 
3、 Content-Type 的值不属于下列之一:
 
  – application/x-www-form-urlencoded
 
  – multipart/form-data
 
  – text/plain
 
条件1并没有匹配，前端采用标准的POST请求；条件三也没有匹配，请求头Content-Type也是标准值：xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
 
主要原因就是条件2，我们定义了非安全的首部字段appId，设值的初衷，就是让服务端通过此它能更方便地来做业务逻辑。
 
在前端把xhr.setRequestHeader('appId', $APPID)去掉之后，浏览器不进行OPTIONS服务器预检测，直接进入业务逻辑，正确发送POST请求，并且跨域成功。
 
到此处，其实仅仅解决我们的跨域问题已经完成了，只要把appId放到请求send数据中去，移除头部appId字段，就能成功进行前后端交互了。但appId这个字段当初放在头部，就是考虑到它有别于业务逻辑，跟业务代码一起放在请求体中不是特别合适，决定再看看有没有其它方法，允许设置自定义头并且成功跨域的方案。
 
感谢mozilla developer，提供了关于跨域非常详细的资料，大家可以看看。里面也提到了我当前场景的解决方案，马上着手开始实践，为了创造一个跨域环境，我先用nginx起一个127.0.0.1:8080的服务器，然后在这个地址中使用XMLHttpRequest 对象，发起目标为192.168.1.6地址的请求，192.168.1.6使用node js创建一个带有基础响应头的服务器，代码如下：
 
 
1
 
2
 
3
 
4
 
5
 
6
 
7
 
8
 
9
 
10
 
11
 
12
 
13
 
 
const http = require('http');
 
const hostname = '192.168.1.6';  //使用ipconfig -all查看本机IP地址，然后使用127.0.0.1地址进行访问
 
const port = 3000;
 
 
 
//支持跨域的服务器搭建
 
const server = http.createServer((req, res) => {
 
  res.statusCode = 200;
 
  res.setHeader('Content-Type', 'application/json;charset=UTF-8');
 
  res.end('{"code":-3,"msg":"APPID不能为空","response":null,"systemDate":"2017-07-13"}');
 
});
 
server.listen(port, hostname, () => {
 
  console.log('Server running at http://'+hostname+':'+port);
 
});
 
使用fiddler查看报文如下：
 
 
1
 
2
 
3
 
4
 
5
 
6
 
7
 
8
 
9
 
10
 
11
 
12
 
13
 
14
 
15
 
16
 
17
 
18
 
19
 
20
 
 
//请求报文如下：
 
OPTIONS http://192.168.1.6:3000/ HTTP/1.1
 
Host: 192.168.1.6:3000
 
Connection: keep-alive
 
Access-Control-Request-Method: GET
 
Origin: http://127.0.0.1:8080
 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36
 
Access-Control-Request-Headers: appid
 
Accept: */*
 
Referer: http://127.0.0.1:8080/dev/SVN_/h5Main/trunk/alipay/virtualCard20170509/src/pages/test/3-new.html
 
Accept-Encoding: gzip, deflate, sdch
 
Accept-Language: zh-CN,zh;q=0.8
 
 
 
//响应如下：
 
HTTP/1.1 200 OK
 
Content-Type: application/json;charset=UTF-8
 
Date: Fri, 14 Jul 2017 15:11:34 GMT
 
Connection: keep-alive
 
Content-Length: 79
 
{"code":-3,"msg":"APPID不能为空","response":null,"systemDate":"2017-07-13"}
 
可以看到通过在前端增加appid请求头，访问node js 搭建的服务器,浏览器触发了OPTIONS 预检验请求，但是服务端的响应头中没有设置Access-Control-Allow-Origin也没有允许OPTIONS请求，它却成功跨域拿到了json数据。发生这种情况首先想到的就是服务器环境不一致，我们后台使用的是java的spring mvc 肯定比node js 复杂千万倍。于是把这个问题反馈给后台同学，他们通过审查配置文件后发现，OPTIONS在java 的 spring MVC 框架中默认是禁止放行的。资料显示，框架认为这是不安全的行为，确实，不仅跨域还添加自定义请求头。于是开始改造后台响应报文，我配合后台一起调试。最后在原有基础上增加如下配置：
 
'Access-Control-Allow-Headers', 'appId' 来允许服务器请求中携带字段appId，如果还有其它字段，可以用逗号分隔填入；
 
'Access-Control-Allow-Methods',': POST, GET, OPTIONS'来允许服务器允许客户端使用 POST, GET 和 OPTIONS 方法发起请求;
 
添加完毕之后，响应头中增加对应字段，可以成功实现带自定义首部字段的跨域通信。
 
 
1
 
2
 
3
 
4
 
5
 
6
 
 
//响应头局部：
 
HTTP/1.1 200 OK
 
Content-Type: application/json;charset=UTF-8
 
Access-Control-Allow-Headers: appId
 
Access-Control-Allow-Methods: POST, GET, OPTIONS
 
Access-Control-Allow-Origin: *
 
但是我们发现每次这种情况都会触发OPTIONS请求，然后再去执行业务逻辑，虽然正常执行了，但是一个请求变成了两个，肯定增加了用户等待时间和服务器资源消耗，于是又在响应头中增加了Access-Control-Max-Age: 86400；表明该响应的有效时间为 86400 秒，也就是 24 小时。在有效时间内，浏览器无须为同一请求再次发起预检请求。浏览器自身维护了一个最大有效时间，如果该首部字段的值超过了最大有效时间，将不会生效。最后同一天内一个接口就只有一次OPTIONS请求啦，大功告成！
 
三：参考资料 stackoverflow、w3 跨域文档、HTTP访问控制

 
文章目录
 
-Xms512m
-Xmx1024m
-XX:PerSize=512M
XX:MaxPersize=1024M
-noverify
参考文献

 
 
刚参加工作，发现每次配置启动时，在
 
 都配置了。虽然也是知道是配置虚拟机的，可是具体有什么用，不晓得。特此记录一下。
 
-Xms512m
-Xmx1024m 
-XX:PerSize=512M 
-XX:MaxPersize=1024M 
-noverify
 
-Xms512m
 
完整格式是：
 
-Xmssize
 
这是一个不标准的选项（标准的选项是所有类型的虚拟机都可以使用的），而这个选项是特定于Java HotSpot Virtual Machine的。意思是设置堆的初始化大小，值的大小必须大于1M并且是1024byte的倍数。默认单位是byte，不过末尾可以使用k或者K去指明单位是kilobytes。同理可以使用m/M,g/G。下面是使用该选项设置堆的初始化大小为6M。
 
-Xms6291456
-Xms6144k
-Xms6m
 
如果你不设置的话，那么堆的初始化大小为老年代和新生代的大小总和。
 
 
 
tips:
 可以使用-Xmn option 或者 -XX:NewSize option来设置新生代的大小。
 
 
-Xmx1024m
 
完整格式是：
 
-Xmssize
 
设置堆的最大大小，也必须为1024的倍数，并且必须大于2m.
 
-XX:PerSize=512M
 
permanent generation（由叫做non-heap），其实就是java虚拟机运行时数据区中的方法区。
 
用来设置方法区触发垃圾回收机制的内层大小。当超过大小就会触发垃圾回收机制。在jdk8中是不建议的，推荐使用-XX:MetaspaceSize替换。
 
 
 
Sets the space (in bytes) allocated to the permanent generation that triggers a garbage collection if it is exceeded. This option was deprecated un JDK 8, and superseded by the -XX:MetaspaceSize option.
 
 
XX:MaxPersize=1024M
 
设置方法区最大大小。同样在jdk8中是不建议的，建议使用 -XX:MaxMetaspaceSize替换。
 
 
 
Sets the maximum permanent generation space size (in bytes). This option was deprecated in JDK 8, and superseded by the -XX:MaxMetaspaceSize option.
 
 
-noverify
 
关闭字节码校验。
 可以参考一下-Xverify:mode 和文章 JVM的noverify选项
 
 
 
 
字节码校验可以验证字节码class文件格式是否满足要求，并且满足约束条件（字节码的魔数这些东西）。
 
 
参考文献
 
垃圾收集器及内存分配策略
 Configuring JVM options and platform properties
 Java hotspot vm options for windows
 Java hotspot vm options for unix