Рекомендации и рекомендации по созданию прокси-дружественного сайта

Question

Это вопрос к разработчикам прокси и плагинов.

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

Но что, если другая сторона тоже беспокоится об этом? Если мы хотим составить набор руководящих принципов и рекомендаций по разработке сайтов для прокси-дружественного сайта, что, по вашему мнению, должно быть на нем? Подумай о крепких орешках, которые тебе пришлось сломать. Помните ли вы те моменты, когда вам хотелось, чтобы разработчик сайта сделал определенную функцию по-другому? Как?

Так как это связано с кодированием, я не думаю, что оно должно идти к ошибке сервера.

Edit: Прочитав комментарий Пекки, я чувствую, что должен добавить еще немного справочной информации.

Существуют сценарии веб-прокси, такие как glype и PHProxy. Поскольку скрипт должен справляться со многими неизвестными условиями, он не может обслуживать многие сайты. Поскольку количество таких сайтов огромно, нет смысла пытаться сделать внутреннюю логику прокси-сервера достаточно сложной, чтобы справиться с этим огромным разнообразием. Здесь плагины пригодятся. Основной сценарий или сценарий base реализует механизм вызова кода подключаемого модуля для отдельных сайтов.

Итак, если прокси-сервер не работает, скажем, facebook.com, как, впрочем, и так, кодер, заинтересованный в вызове, проводит некоторое исследование и отладку, чтобы найти, где и почему разрыв цепи и что должно быть сделано, чтобы решить проблему. Кодер реализует свое исправление как плагин для этого конкретного сайта, и пользователи могут добавить плагин в каталог плагинов.

Но бывает и так, что что-то на сайте меняется, и это изменение вызывает плагин снова ломается. Так что это постоянное совпадение, чтобы быть в курсе последних изменений сайта. Ирония ситуации заключается в том, что многие разработчики сайтов не знают и не заботятся о том, какое влияние их дизайнерские решения могут оказать на прокси-способность контента. Но у некоторых сайтов есть веская причина заботиться о возможности посетителей получать доступ к своему контенту через прокси. Я не хочу вдаваться в политику, поэтому я оставляю вас догадываться, почему это может быть важно для некоторых сайтов.

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

Изначально я не помечал вопрос php, поскольку он в основном касается вывода сайта, а не того, как вы его генерируете. Но решил пометить его так, потому что это улучшит видимость вопроса, и этот тег может быть оправдан и для целевой аудитории. Я также создаю эту вики-страницу сообщества, так что если вы считаете, что php-тег должен быть удален, просто сделайте это.

Answer 1

Я не уверен, волнует ли вас это или нет, но в настоящее время я помню только две вещи, о которых следует позаботиться при работе на дружественном прокси-сайте. Один - заголовок, который может влиять на сайты, посещаемые через прокси, а другой - обнаружение IP. Заголовок контроля кэша (публичный / приватный) и другие заголовки могут влиять на скорость и конфиденциальность пользователя. IP обнаружил может прокси, а не пользователя. Итак, об этом нужно помнить.

Answer 2

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

Традиционный способ решения этой проблемы - наличие опубликованного API, который позволяет третьим сторонамзапрашивать данные, которые они хотят, контролируемым образом, который не зависит от очистки экрана.API часто предоставляет только подмножество функций, обычно потому, что сайт требует от пользователей, просматривающих страницы, генерировать рекламный доход (или какой-либо другой вид дохода).

Вы можете создавать очень простые страницы, фактически используяHTML API и используйте Javascript и CSS, чтобы сделать страницы более удобными для пользователя.Однако это может не подходить для большинства сайтов.Но подход «прогрессивного улучшения», о котором трубят jQuery и другие, имеет те же черты: обслуживать базовый, семантический контент и добавлять функциональность и Pizzazz через JS и CSS.

Вы можете использовать микроформаты, чтобы сделать определенный контент страницы более доступным,Вам следует использовать семантический HTML-код и размещать множество классов и идентификаторов на элементах страницы, чтобы авторы плагинов могли найти нужный им контент.

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

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