azproduction 8 июн 2011 в 19:07

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

9 мин

84K

JavaScript*

Перевод

+125

Комментарии 32

stell_hawk 8 июн 2011 в 19:50

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

lesha_penguin 8 июн 2011 в 20:03

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

azproduction 8 июн 2011 в 20:06

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

lesha_penguin 8 июн 2011 в 20:25

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

Demetros 8 июн 2011 в 21:35

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

azproduction 8 июн 2011 в 20:04

В спецификации 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 8 июн 2011 в 20:00

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

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

Toy 8 июн 2011 в 20:09

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

mr_avi 8 июн 2011 в 22:41

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

tibalt 10 июн 2011 в 08:32

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

JhaoDa 8 июн 2011 в 20:23

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

sulla 8 июн 2011 в 21:38

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

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

Vidmich 9 июн 2011 в 12:55

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

trigger1 8 июн 2011 в 20:33

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

JhaoDa 8 июн 2011 в 21:04

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

Demetros 8 июн 2011 в 21:32

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

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

sulla 8 июн 2011 в 21:48

<?php

// можно ограничить домен, для которого доступен ответ

header('Access-Control-Allow-Origin: javascript.ru');

?>

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

Demetros 8 июн 2011 в 21:51

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

sulla 8 июн 2011 в 21:59

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

Предлагаемые решения были такими:
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 8 июн 2011 в 22:09

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

azproduction 8 июн 2011 в 22:58

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

Demetros 9 июн 2011 в 10:16

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

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

vkramskikh 8 июн 2011 в 22:39

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

azproduction 8 июн 2011 в 23:23

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

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

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

vkramskikh 9 июн 2011 в 11:13

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

Kolyaj 9 июн 2011 в 12:00

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

vkramskikh 9 июн 2011 в 12:04

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

andoriyu 9 июн 2011 в 04:57

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

Homakov 9 июн 2011 в 20:57

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

andoriyu 9 июн 2011 в 23:39

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

НЛО прилетело и опубликовало эту надпись здесь

barmaley_exe 14 июн 2011 в 23:56

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

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

Комментарии 32

Публикации

Истории