Невозможно получить настраиваемый заголовок с помощью $ http [duplicate]
Во всех этих сценариях outerScopeVar изменяется или назначается значение асинхронно или происходит в более позднее время (ожидание или прослушивание какого-либо события), для которого текущее выполнение не будет ждать. Таким образом, все эти случаи текущего потока выполнения приводит к outerScopeVar = undefined
Давайте обсудим каждый пример (я обозначил часть, которая называется асинхронно или задерживается для возникновения некоторых событий):
1.
Здесь мы регистрируем eventlistner, который будет выполнен на этом конкретном событии. Загрузите изображение. Затем текущее выполнение будет продолжено со следующими строками img.src = 'lolcat.png'; и alert(outerScopeVar);, между тем событие может не произойти. т. е. funtion img.onload ожидают, что упомянутое изображение будет загружаться, как можно скорее. Это будет происходить во всем следующем примере: событие может отличаться.
2.
Здесь событие тайм-аута играет роль , который вызывается обработчиком по истечении указанного времени. Здесь 0, но все же он регистрирует асинхронное событие, которое будет добавлено в последнюю позицию Event Queue для выполнения, что делает гарантированную задержку.
3.
На этот раз ajax обратный вызов.
4.
Узел можно рассматривать как король асинхронного кодирования. Если отмеченная функция зарегистрирована как обработчик обратного вызова, которая будет выполнена после чтения указанного файла.
5.
Очевидное обещание (что-то будет сделано в будущем) является асинхронным. см. . Каковы различия между отложенными, обещаниями и будущими в JavaScript?
https://www.quora.com/Whats-the-difference-between-a -promise-и-обратный вызов-в-Javascript
2 ответа
CORS реализован таким образом, что он не нарушает предположений, сделанных в пре-CORS, мире с единственным источником.
В мире pre-CORS клиент может запускать крест -origin (например, с помощью тега скрипта), но он не смог прочитать заголовки ответов.
Чтобы гарантировать, что CORS не нарушит это предположение, спецификация CORS требует, чтобы сервер выдавал явные разрешения для чтения клиентом этих заголовков (через заголовок Access-Control-Expose-Headers). Таким образом, несанкционированные запросы CORS ведут себя так же, как в мире pre-CORS.
Это довольно хороший вопрос. Просматривая http://www.w3.org/TR/cors/#simple-response-header , неясно, зачем вам это нужно или нужно сделать.
Спецификация CORS вкладывает большой вес в идею о том, что у вас должно быть рукопожатие предварительного запроса, когда клиент запрашивает тип соединения, и сервер отвечает, что он это разрешит, - поэтому это может быть просто еще одним аспектом этого.
По умолчанию длина содержимого не является допустимым заголовком, поэтому я столкнулся с той же проблемой (позже, когда мне нужно было получить доступ к WebDAV и пришлось модифицировать допустимые параметры). CORS действительно не делает во многом это чувство (для меня), поэтому меня это не удивило бы, если бы это были капризы.
-
1– monsur 4 September 2014 в 20:29
-
2– mcdave 25 November 2015 в 03:50