Задачи обмена информацией ставятся и успешно решаются каждый день. Но обмениваться можно по-разному. Кто-то дарит удобоваримый доступ к своей базе посредством распространённых обменных форматов (xml, csv, json, lisiy_chert), кто-то реализует собственные API, а кто-то идёт другими путями.
Моя задача состояла в следующем – на ресурсах-сателитах необходимо разместить сложную форму. “Сложность” формы заключается в том, что данные подгружаются с главного ресурса и не могут быть загружены единовременно(при загрузке ресурса) или доставлены на ресурс-сателит заранее (так-так данных очень много и они достаточно быстро устаревают). Всевозможные API для доступа к информации основного ресурса в настоящий момент разрабатывать нецелесообразно, поэтому было решено для сателитов предоставлять некий готовый комплекс (аля plug-n-play).
Ещё до начала разработки я тщательно изучил уже имеющиеся механизмы для межсайтового обмена данными. Первым и самым перспективным был вариант использования flash-плеера, но единственный вменяемый пример FlashXmlHttpRequest был только лишь примером, а не законченным куском кода, которым бы можно было воспользоваться. jQuery на тот момент даже не содержала функции $.getScript, JSHttpRequest с созданием тега script удачно справлялся, но POST по понятным причинам делать не мог.
Данные с главного ресурса могут подгружатся посредством динамического создания тега script jQuery.getScript, с этим казалось бы проблемы нет. Но! Но последним шагом в указанной форме нужно отправить на основной сервер внушительный объём данных, которые могут не влезть в GET (тоже кстати говоря весьма интересный вопрос – а каково ограничение на длину URL в разных браузерах? в различных веб-серверах,прокси и фильтрах? – в RFC2616 об этом не сказано). Можно конечно изобрести какие-либо механизмы, например отправлять данные небольшими порциями GET-ом, но скорости такая схема явно не прибавит, поэтому такие варианты оставлены другим изобретателям.
В первом рабочем варианте проблема решалась php-скриптом на сервере-сателите, через который данные POST-ом прокачивались на головной сайт. Но такая схема имела ряд недостатков, основным из которых опять же является скорость работы и дополнительное требование к ПО на сервере (наличие PHP) или требование к нам, разработчикам – создать прокси-скрипт для других распространнёных серверных платформ.
И вот относительно недавно я наткнулся на занимательную библиотеку flxhr. Автор довёл до конца идею и наваял интерфейс, который может прозрачно заменять XMLHttpRequest используя flash. Использовать flxhr легко и просто – заменяете стандартный XMLHTTPRequest и дальше всё почти как обычно.
В дополнение ко всему, флеш-плеер решает ещё одно требование к разрабатываемому проекту – необходимо пресечь бесконтрольное распространение клиентского модуля(который устанавливается на сайт-сателит). Дело в том что в флеш-плеер от рождения встроен механизм контроля над внешними данными. Ранее это был ресурс crossdomain.xml в корне веб-сервера, содержащего скачиваемые данные. В нём описывалось откуда и что можно скачать. В новом плеере (а для использования flxhr необходим плеер версии не ниже 9.0.0.124) появился более удобный механизм – можно указать путь к ресурсу с политиками policyURL.
Кстати о версии плеера: автор flxhr предусмотрел не только проверку версии плеера, но и возможность его апгрейдить не отходя от кассы (тот самый expressinstall из swfobject).
Думаю стоит ещё раз упомянуть тот факт, что данная схема не позволит обратиться js-скрипту с произвольного сайта A на произвольный ресурс B без согласия его владельца. “Согласие” выражается в виде правил, описываемых в файле crossdomain.xml(или указанным в loadPolicyFile), который располагается на сервере B. Другими словами данные, которые вы желаете публиковать, не должны быть “ворованными”.
Единственным неудобством, с которым пока довелось столкнуться в ходе обкатки flxhr, является тот факт, что данные в кодировке отличной от UTF-8 безвозвратно портятся. В остальном это самый лёгкий и удобный способ обмениваться данными между разными доменами уже сейчас, не дожидаясь появления сверхновых версий браузеров, в которых реализуют XMLHttpRequest Level 2, и скоропостижной смерти всех старых.
Я прошу прощения, у меня возник вопрос – не могли бы вы пояснить по поводу JsHttpRequest и POST – точнее затруднения связаные с этим вопросом
Сам использую этот класс, и потому заинтересован знать слабину.
Сам использовал POST для отсылки файлов через эту функцию, и проблем не возникало.
Может специфика вашего проекта. О ваших требованиях прочитал, и согласен что dklab вариант вам действительно не подходит, но вопрос с POST…
В сумме с интересом выслушаю вас
Пояснения прямо в названии статьи – мне нужен POST-запрос на другой домен и обработка результатов этого запроса.
По поводу GET запроса – по-моему во всех браузерах ограничение до 256 символов
Это не так. Во всех доступных сейчас под рукой браузерах не меньше 1024, в некоторых до 4096.