Как стать автором
Обновить

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

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

В юзкейсах спецификаций w3с очень много идей для старапов — советую почитать ;) Вот, например, юзкейсы FileSystem API
Идеи-то конечно есть, я говорю о том, но пока еще нет сервисов, которые эти идеи реализовывали бы в качестве «killer feature» пока нет. Так что, спасибо за хорошую статью — будет над чем подумать.
Дозагрузка через FileAPI и Silverlight уже достаточно давно работает у нас на files.mail.ru
Правда для инициации дозагрузки в случае обрыва и т.п. всё-таки надо повторно выбрать файл в диалоге.
В спецификации 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 — можем сохранять процесс аплоада файла и восстановить его после обрыва, закрытия окна
которые положат конец нашим безумным хакам и пляскам с бубном

Пока живы ИЕ 6-8, не положат:(
Пока разработчики не положат на ИЕ 6-8, они будут жить.
Иногда проще написать под ИЕ6, чем потом мучаться с пользователями ИЕ:)
разработчики ведь не сами формируют требования. этим занимается заказчик.
Ну так-то да, пока еще это использовать массово нельзя. Но кто мешает использовать не массово? Те же FormData, DragDrop и DataTransfer сильно облегчают мне жизнь при написании, например, админок. Просто я говорю клиенту, что админка будет работать только в FF4 и Chrome — никто пока не возражал.
В IE8-9 и правда есть XDomainRequest, но там не все так хорошо как кажется. Во первых нельзя передавать свои хедеры, вообще. во вторых они даже Content-Type посчитали несекьюрным, так что на серверную сторону запросы приходят без него и приходится rewriterul'ами его добавлять чтобы серверная сторона начала распарссивать форму в пост данных. С http referer тоже проблемы. Так что пока IE не реализует level2 вокруг него еще плясать и плясать с бубном…
Респект!
Утащил к себе. Спасибо за инфу )
А вообще, конечно, всё это — HTML5, CSS3, всякие новые вкусные API — очень радует. Вспоминая, что и как приходилось городить 2, 5, 8 лет назад — так сейчас просто рай для разработчика…
Заголовок Access-Control-Allow-Origin может быть выдан одному сайту или целому поддомену или даже любому сайту с любого домена

Как разрешить запросы для нескольких выбранных доменов, например example.com и anotherexample.com? Только без предположений и гаданий на кофейной гуще, а рабочий способ, пожалуйста.
<?php
// можно ограничить домен, для которого доступен ответ
header('Access-Control-Allow-Origin: javascript.ru');
?>

The Access-Control-Allow-Origin header should contain a comma separated list of acceptable domains. (документация)
А вы пробовали так сделать, работает?
Задача так не стояла — не пробовал,
хотя натыкался на проблему не работоспособности.

Предлагаемые решения были такими:
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"


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

*ради интереса надо попробовать.
Вот и у меня, когда я пробовал (правда было это наверно полгода назад) как-то не заработало оно…
Специально проверил. Firefox понимает только формат Access-Control-Allow-Origin: origin | * ни списки ни многозаголовочность не понимает.
Работает вот так:
Access-Control-Allow-Origin: http://bla-lba.ru
или так:
Access-Control-Allow-Origin: *
Т.е. насколько я понимаю пока самый кроссбраузерный вариант — это

1. На клиенте считать Origin header, сравнить с теми что сами разрешаем, и отдать только разрешенный адрес в Access-Control-Allow-Origin
Я все правильно понимаю, кроссдоменный запрос придет в любом случае, просто клиент может не получить на него ответ? И при этом все куки передаются?
Необходимо выставить флаг withCredentials — по умолчанию данные пользователя (Cookie, Authorization, клиентские сертификаты) не передаются.
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://example.com/');
xhr.withCredentials = true; // <<<

Чтобы все работало сервер должен выставить заголовок Access-Control-Allow-Credentials: true
Если это так, то это небезопасно, теперь можно проводить CSRF-атаки вообще без ведома пользователя. Сервер такой запрос все равно получит и обработает, вне зависимости от наличия нужных заголовков в ответе
Ничто не мешает это делать и без XHR2. Создаём динамически форму и отправляем её в скрытый iframe.
Насколько помню, в ифреймы с других доменов куки не передаются. Это поведение настраивается у многих браузеров в настройках безопасности, и по умолчанию именно такое. Хотя последний раз я с этим сталкивался довольно давно, возможно, сейчас дела обстоят иначе
Маленько не понимаю почему именно так работает. Логичнее было бы ограничивать ресурсы на стороне сервера который обслуживает клиент, а не там куда надо сделать запрос (ну или оба). Так я много чего не хорошего сделать в случае если попадется ресурс где можно заинжектит JS код.
точно, странное решение, ничего не дающее. опечатка?
Неа, я еще когда черновики только появились задался этим вопросом.
НЛО прилетело и опубликовало эту надпись здесь
В статье мелькает свойство upload xhr объекта, которое, между тем, является полезным при мониторинге прогресса запроса.
Это самое свойство — ссылка на соответствующий экземпляр XMLHttpRequestUpload, которому можно назначить обработчики на следующие события: onloadstart, onprogress, onabort, onerror, onload, ontimeout, onloadend.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории