Защо неперсонализираните заглавки са включени в Access-Control-Request-Headers?

Опитвам се да изпратя заявка за кръстосан произход. Що се отнася до Access-Control-Request-Headers, получавам различно поведение във FireFox, Chrome и Safari.

Chrome :- Access-Control-Request-Headers:  origin, content-type, accept
Safari :- Access-Control-Request-Headers:  origin, content-type, accept
Firefox:- Access-Control-Request-Headers:  content-type

Въпросите ми са:-

  1. Как браузърите решават кои заглавки ще бъдат част от Access-Control-Request-Headers?
  2. Доколкото знам, трябва да има само персонализирани заглавки в Access-Control-Request-Headers, но и трите (accept,origin и content-type) не са персонализирани заглавки. Тогава защо са част от Access-Control-Request-Headers?
  3. Защо поведението варира според браузъра?

google-chrome cors ajax http-headers firefox
person maneet    schedule 26.06.2013    source източник

Отговори (1)


arrow_upward
9
arrow_downward

Тук се случват много различни неща, така че ще отговоря едно по едно.

Chrome и Safari са базирани на WebKit, поради което виждате същото поведение в тези браузъри (Chrome скоро ще премине към Blink, но това все още не е в ръцете на потребителите).

Последната спецификация на CORS гласи, че Accept е проста заглавка на заявка. Origin не е включен в списъка с прости заглавки на заявки, но би било глупаво да не се поддържа, тъй като е основата на CORS. Така че технически Firefox прави правилното нещо.

Обърнете внимание обаче, че въпреки че Chrome/Safari включва заглавките Accept и Origin, те не проверяват дали тези заглавки са включени в заглавката на отговора Access-Control-Allow-Headers. Можете да проверите това, като посетите следната връзка:

http://client.cors-api.appspot.com/client#?client_method=PUT&client_credentials=false&client_headers=Accept%3A%20%2A%2F%2A&server_enable=true&server_status=200&server_credentials=false&server_methods=PUT&server_tabs=local

Имайте предвид, че заявката за предполет има заглавка Access-Control-Request-Headers: accept, origin, но няма Access-Control-Allow-Headers в отговора. И действителната заявка на CORS все още е успешна.

Заглавието Content-Type се счита за просто заглавие на заявка само когато стойността му е едно от следните: application/x-www-form-urlencoded, multipart/form-data или text/plain. Всички други стойности ще задействат предполет. Вероятно това е, което виждате тук.

Нямам представа защо браузърите се държат по този начин. Може да е нещо, което си струва да попитате в таблата за съобщения на WebKit или Firefox. Ето кода, където WebKit задава заглавката Access-Control-Request-Headers:

https://trac.webkit.org/browser/trunk/Source/WebCore/loader/CrossOriginAccessControl.cpp?order=name#L117

Изглежда, че изброява всички заглавки, без да премахва простите заглавки. Предполагам, че има код от страната на отговора, който очаква само непрости заглавки в отговора Access-Control-Allow-Headers.

person monsur    schedule 27.06.2013
comment
здравейте още нещо, използвайки chrome, задавам стойност на заглавката dauth. но във fiddler ми показва Access-Control-Request-Headers:content-type, dauth, x-akamai-acs-action. Като има предвид, че ако аз --disbale-web-security за chrome ми показва DAUTH: XXXXXXX стойност....някаква идея защо не добавя стойност на заглавка в предишен случай - person Taran; 12.10.2015