1.0Чудо{вищные} заметкиhttps://miracle.rpz.nameMiRacLehttps://miracle.rpz.name/author/miracle/Задачи обмена информацией ставятся и успешно решаются каждый день. Но обмениваться можно по-разному. Кто-то дарит удобоваримый доступ к своей базе посредством распространённых обменных форматов (xml, csv, json, lisiy_chert), кто-то реализует собственные API, а кто-то идёт другими путями. Моя задача состояла в следующем - на ресурсах-сателитах необходимо разместить сложную форму. "Сложность" формы заключается в том, что данные подгружаются с главного ресурса и не могут быть загружены единовременно(при загрузке ресурса) или доставлены на ресурс-сателит заранее (так-так данных очень много и они достаточно быстро устаревают). Всевозможные API для доступа к информации основного ресурса в настоящий момент разрабатывать нецелесообразно, поэтому было решено для сателитов предоставлять некий готовый комплекс (аля plug-n-play). <blockquote> Ещё до начала разработки я тщательно изучил уже имеющиеся механизмы для межсайтового обмена данными. Первым и самым перспективным был вариант использования flash-плеера, но единственный вменяемый пример <a href="http://blog.monstuff.com/archives/000294.html">FlashXmlHttpRequest</a> был только лишь примером, а не законченным куском кода, которым бы можно было воспользоваться. <a href="http://jquery.com/">jQuery</a> на тот момент даже не содержала функции $.getScript, <a href="http://dklab.ru/lib/JsHttpRequest/">JSHttpRequest</a> с созданием тега script удачно справлялся, но POST по понятным причинам делать не мог. </blockquote> Данные с главного ресурса могут подгружатся посредством динамического создания тега script <a href="http://docs.jquery.com/Ajax/jQuery.getScript">jQuery.getScript</a>, с этим казалось бы проблемы нет. Но! Но последним шагом в указанной форме нужно отправить на основной сервер внушительный объём данных, которые могут не влезть в GET (тоже кстати говоря весьма интересный вопрос - а каково ограничение на длину URL в разных браузерах? в различных веб-серверах,прокси и фильтрах? - в <a href="http://www.ietf.org/rfc/rfc2616.txt">RFC2616</a> об этом не сказано). Можно конечно изобрести какие-либо механизмы, например отправлять данные небольшими порциями GET-ом, но скорости такая схема явно не прибавит, поэтому такие варианты оставлены другим изобретателям. <!--more--> В первом рабочем варианте проблема решалась php-скриптом на сервере-сателите, через который данные POST-ом прокачивались на головной сайт. Но такая схема имела ряд недостатков, основным из которых опять же является скорость работы и дополнительное требование к ПО на сервере (наличие PHP) или требование к нам, разработчикам - создать прокси-скрипт для других распространнёных серверных платформ. <strike>И вот относительно недавно</strike> я наткнулся на занимательную библиотеку <a href="http://flxhr.flensed.com/">flxhr</a>. Автор довёл до конца идею и наваял интерфейс, который может <b>прозрачно заменять XMLHttpRequest</b> используя flash. Использовать flxhr легко и просто - <a href="http://flxhr.flensed.com/code/tests/flxhr-7f.html">заменяете стандартный XMLHTTPRequest</a> и дальше всё почти как обычно. В дополнение ко всему, флеш-плеер решает ещё одно требование к разрабатываемому проекту - необходимо пресечь бесконтрольное распространение клиентского модуля(который устанавливается на сайт-сателит). Дело в том что в флеш-плеер от рождения встроен механизм контроля над внешними данными. Ранее это был ресурс crossdomain.xml в корне веб-сервера, содержащего скачиваемые данные. В нём описывалось откуда и что можно скачать. В новом плеере (а для использования flxhr необходим плеер версии не ниже 9.0.0.124) появился более удобный механизм - можно указать путь к ресурсу с политиками <a href="http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html#goal_control">policyURL</a>. <blockquote> Кстати о версии плеера: автор flxhr предусмотрел не только проверку версии плеера, но и возможность его апгрейдить не отходя от кассы (тот самый <a href="http://blog.deconcept.com/swfobject/#expressinstall">expressinstall из swfobject</a>). </blockquote> Думаю стоит ещё раз упомянуть тот факт, что данная схема <b>не позволит</b> обратиться js-скрипту с произвольного сайта A на произвольный ресурс B без согласия его владельца. "Согласие" выражается в виде правил, описываемых в файле crossdomain.xml(или указанным в loadPolicyFile), который располагается на сервере B. Другими словами данные, которые вы желаете публиковать, не должны быть "ворованными". Единственным неудобством, с которым пока довелось столкнуться в ходе обкатки flxhr, является тот факт, что данные в кодировке отличной от UTF-8 безвозвратно портятся. В остальном это самый <b>лёгкий и удобный</b> способ обмениваться данными между разными доменами уже <b>сейчас</b>, не дожидаясь появления сверхновых версий браузеров, в которых реализуют <a href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2/">XMLHttpRequest Level 2</a>, и скоропостижной смерти всех старых. rich