Новые возможности XMLHttpRequest2

[stell_hawk]

Действительно много интересного добавили.
Давно уже хочу такую штуку чтобы сделали, возможность дозагрузки файла на сервер, в случае обрыва.
зашел в свой интрефейс а там запись что файл загружали, и возможность дозалить его на сервер, я думаю что обменник с таким сервисом давно бы всех победил.

[lesha_penguin]

Вот вы сами только что произнесли годную идею для стартапа: файлообменник с возможность дозаливки при обрыве. Если технически реализуете эту идею быстрее чем другие — получите профит.

[azproduction]

В юзкейсах спецификаций w3с очень много идей для старапов — советую почитать ;) Вот, например, юзкейсы FileSystem API

[lesha_penguin]

Идеи-то конечно есть, я говорю о том, но пока еще нет сервисов, которые эти идеи реализовывали бы в качестве «killer feature» пока нет. Так что, спасибо за хорошую статью — будет над чем подумать.

[Demetros]

Дозагрузка через FileAPI и Silverlight уже достаточно давно работает у нас на files.mail.ru
Правда для инициации дозагрузки в случае обрыва и т.п. всё-таки надо повторно выбрать файл в диалоге.

[azproduction]

В спецификации FileSystem API даже есть такой юзкейс:

Persistent uploader
— When a file or directory is selected for upload, it copies it into a local sandbox and uploads a chunk at a time.
— It can restart uploads after browser crashes, network interruptions, etc.

1. Мы можем скопировать файл в хранилище FileSystem API и дозагружать из него — пользователю не нужно повторно выбирать файл, мы уверены, что файл не изменится
2. У XHR2 есть событие «progress» в котором сообщается сколько байт файла уже загрузилось — можем узнать сколько уже загрузилось
3. Мы можем делить файлы на более мелкие (Пример 2: Отправка файла по частям) — можем именно дозагружать
4. У нас есть localStorage — можем сохранять процесс аплоада файла и восстановить его после обрыва, закрытия окна

[mr_avi]

которые положат конец нашим безумным хакам и пляскам с бубном

Пока живы ИЕ 6-8, не положат:(

[Toy]

Пока разработчики не положат на ИЕ 6-8, они будут жить.

[mr_avi]

Иногда проще написать под ИЕ6, чем потом мучаться с пользователями ИЕ:)

[tibalt]

разработчики ведь не сами формируют требования. этим занимается заказчик.

[JhaoDa]

Ну так-то да, пока еще это использовать массово нельзя. Но кто мешает использовать не массово? Те же FormData, DragDrop и DataTransfer сильно облегчают мне жизнь при написании, например, админок. Просто я говорю клиенту, что админка будет работать только в FF4 и Chrome — никто пока не возражал.

[sulla]

Для ie8 есть XDomainRequest
В связке с XMLHTTPRequest 2, работает начиная с Firefox 3.5/Safari 4/IE8.

Пример и пояснения можно посмотреть тут.

[Vidmich]

В IE8-9 и правда есть XDomainRequest, но там не все так хорошо как кажется. Во первых нельзя передавать свои хедеры, вообще. во вторых они даже Content-Type посчитали несекьюрным, так что на серверную сторону запросы приходят без него и приходится rewriterul'ами его добавлять чтобы серверная сторона начала распарссивать форму в пост данных. С http referer тоже проблемы. Так что пока IE не реализует level2 вокруг него еще плясать и плясать с бубном…

[trigger1]

Респект!
Утащил к себе. Спасибо за инфу )

[JhaoDa]

А вообще, конечно, всё это — HTML5, CSS3, всякие новые вкусные API — очень радует. Вспоминая, что и как приходилось городить 2, 5, 8 лет назад — так сейчас просто рай для разработчика…

[Demetros]

Заголовок Access-Control-Allow-Origin может быть выдан одному сайту или целому поддомену или даже любому сайту с любого домена

Как разрешить запросы для нескольких выбранных доменов, например example.com и anotherexample.com? Только без предположений и гаданий на кофейной гуще, а рабочий способ, пожалуйста.

[sulla]

<?php
// можно ограничить домен, для которого доступен ответ
header('Access-Control-Allow-Origin: javascript.ru');
?>

The Access-Control-Allow-Origin header should contain a comma separated list of acceptable domains. (документация)

[Demetros]

А вы пробовали так сделать, работает?

[sulla]

Задача так не стояла — не пробовал,
хотя натыкался на проблему не работоспособности.

Предлагаемые решения были такими:
1. На клиенте считать Origin header, сравнить с теми что сами разрешаем, и отдать только разрешенный адрес в Access-Control-Allow-Origin
2. Отправить вот так:
Access-Control-Allow-Origin: domain1.com
Access-Control-Allow-Origin: domain2.com
Access-Control-Allow-Origin: domain3.com
Для апача с использование mod_headers в .htaccess
Header add Access-Control-Allow-Origin "http://domain1.com"
Header add Access-Control-Allow-Origin "http://domain2.com"
Header add Access-Control-Allow-Origin "http://domain3.com"

Для любознательных спецификация.

*ради интереса надо попробовать.

[Demetros]

Вот и у меня, когда я пробовал (правда было это наверно полгода назад) как-то не заработало оно…

[azproduction]

Специально проверил. Firefox понимает только формат Access-Control-Allow-Origin: origin | * ни списки ни многозаголовочность не понимает.
Работает вот так:
Access-Control-Allow-Origin: http://bla-lba.ru
или так:
Access-Control-Allow-Origin: *

[Demetros]

Т.е. насколько я понимаю пока самый кроссбраузерный вариант — это

1. На клиенте считать Origin header, сравнить с теми что сами разрешаем, и отдать только разрешенный адрес в Access-Control-Allow-Origin

[vkramskikh]

Я все правильно понимаю, кроссдоменный запрос придет в любом случае, просто клиент может не получить на него ответ? И при этом все куки передаются?

[azproduction]

Необходимо выставить флаг withCredentials — по умолчанию данные пользователя (Cookie, Authorization, клиентские сертификаты) не передаются.

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://example.com/');
xhr.withCredentials = true; // <<<

Чтобы все работало сервер должен выставить заголовок Access-Control-Allow-Credentials: true

[vkramskikh]

Если это так, то это небезопасно, теперь можно проводить CSRF-атаки вообще без ведома пользователя. Сервер такой запрос все равно получит и обработает, вне зависимости от наличия нужных заголовков в ответе

[Kolyaj]

Ничто не мешает это делать и без XHR2. Создаём динамически форму и отправляем её в скрытый iframe.

[vkramskikh]

Насколько помню, в ифреймы с других доменов куки не передаются. Это поведение настраивается у многих браузеров в настройках безопасности, и по умолчанию именно такое. Хотя последний раз я с этим сталкивался довольно давно, возможно, сейчас дела обстоят иначе

[andoriyu]

Маленько не понимаю почему именно так работает. Логичнее было бы ограничивать ресурсы на стороне сервера который обслуживает клиент, а не там куда надо сделать запрос (ну или оба). Так я много чего не хорошего сделать в случае если попадется ресурс где можно заинжектит JS код.

[Homakov]

точно, странное решение, ничего не дающее. опечатка?

[andoriyu]

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

[barmaley_exe]

В статье мелькает свойство upload xhr объекта, которое, между тем, является полезным при мониторинге прогресса запроса.
Это самое свойство — ссылка на соответствующий экземпляр XMLHttpRequestUpload, которому можно назначить обработчики на следующие события: onloadstart, onprogress, onabort, onerror, onload, ontimeout, onloadend.