Форум » » Парсим HTML » Ответить

Парсим HTML

Вячеслав: Есть некоторая проблемка с разбором ответов от HTTP сервера устройств. Стало модной фишкой упаковывать ответы сервера qzip. Кто нибудь заморачивался с такой проблемой? Может модулек какой писали для распаковки и т.п.

Ответов - 23, стр: 1 2 All

gosha: Ээээ, а в запросе какой Content-Type: стоит?

Вячеслав: Под рукой нет. Скорее всего это поле не указывал. Что рекомендуете поставить? text/html?

gosha: А что документация по API говорит? А вообще, хочется посмотреть на .pcap запроса и ответа...


Вячеслав: Да какая там документация )) Это QNAP хранилище. Нужен статус того что есть активные закачки в Download Station (торрент). В telnet такой информации производитель не предусмотрел. Но у самой Download Station есть web страничка, с которой и пытался запарсить статус "Загружается" отправив GET запрос с crestron. В ответ вывалило портянку с указанием что блок данных сжат qzip (или типа того). Следовательно find-ом там парсить нечего среди этого пожатого архиватором крокозябла.

p.vladi: GET запросы (header) правильно оФормите, а не скопируйте как ваш браузер посылает Qnap не будет сжимать если будет думать что у вас страрый броузер

eoulianov: Но зачем знать про закачки? Пользователю показывать - так проще браузер ему открыть, или хотите хранилище гасить или интернет канал?

Игорь K.: Такая экзотика, граничащая с чем то безумным есть только на русском форуме.

Вячеслав: p.vladi пишет: GET запросы (header) правильно оФормите, а не скопируйте как ваш браузер посылает Qnap не будет сжимать если будет думать что у вас страрый броузер Я не копировал с браузера,использовал минимальный набор полей запроса достаточный для DUNE например Какое именно поле HEADER рекомендуете использовать в запросе? Да, некоторых безумцев раздражает хранилище пыхтящее дисками круглые сутки Включаю автоматически только когда есть клиенты в домашней сети и выключаю,когда клиентов нет. Другой случай, когда поставил на закачку и все ТВ, ПК отключены. А выключать то нельзя пока не закачается. Кнопочка с переводом в ручной режим это не наш метод, мы же тут автоматизацией занимаемся

eoulianov: Обновится же в этом хранилище торрент-клиент, и размажется вся его web-морда, а то и вовсе в https уйдёт. Посмотрите лучше, нельзя ли там встроенными возможностями или какими-то плагинами усыплять диски при неиспользовании, хотя торрент-клиент их как раз будет юзать. Я-то подумал, что вы планировали показывать попап-окошки на всех панелях в духе "Закачка <Крутое-Порно-115.AVI> завершена!")

Игорь K.: Вячеслав, неужели вы думаете, что QNAP делали полные безумцы? По-умолчанию, если нет активных подключений, то NAS автоматом уходит в спящий режим. Так, например, работают все серверы Synology. Лучший выход - тщательно настроить каждый элемент системы, чтобы не городить адские контуры управления и быть связанным по рукам и ногам и иметь рельсы в колёсах.... Это моё личное мнение, никому не навязываю.

Вячеслав: К сожалению от техподдержки QNAP получить информацию о статусе режима sleep получить не удалось (официальный ответ "режим не документирован"). Ну не тестером же измерять энергопотребление. Никакого визуального эффекта от того,что хранилище ушло в режим энергосбережения нет,шуршит себе дисками и лампочками мигает. Может оно и не ушло (хотя все раздачи в Pause) и никто диски не использует уже как полдня, но зачем мне гадать если можно управлять, я то точно знаю нужно мне хранилище в данный момент или нет. Маркетологи QNAP и так вволю всех .... Стоп!!! Меня вынудили сказать про какое именно устройство идет речь. Тема была внесена на обсуждение более глобальная. Про HTTP и qzip. Необходимость управления оборудованием по HTTP популярная задача и набирающий популярность qzip может поставить палки в колеса. Этому собственно пост и посвящен. Давайте абстрагируемся от QNAP. А какую логику управления устройством по HTTP мы будем применять уже дело персональное (тем более у себя дома). Будем решать проблемы по мере их поступления.Будет HTTPS будем искать решения для него. Отдельное спасибо за ненавязчивость.

gosha: HTTP - всего лишь метод передачи запросов и получения ответов. Запрос состоит из метода, опциональных дополнительных полей (headers) и опционального контента. Ответ состоит из кода ответа, опциональных дополнительных полей и опционального контента. И в этом плане HTTP отличается от, например, SIP или UPnP только названиями методов и полей. Конкретные наименования полей и содержимое контента определяется конкретной реализацией. Так что вопрос более глобален - кто как разбирает подобного рода протоколы.

Вячеслав: qosha не надо вот так совсем то абстрактно, а то злые языки начнут говорить а при чем тут crestron и отправят меня на форум web-программистов. Надеялся, кто то уже сталкивался с подобным и нашел решение не сопровождаемое словами "а ну и хр с ним и махом руки в направлении up-down"/. Ладно, спасибо откликнувшимся погуглю на более тематических к HTML форумах.

gosha: Вячеслав: у вас порочная связь HTTP и web/html. Разорвите ее - и все встанет на свои места. HTML - это всего лишь тип контента, причем вовсе не обязательный и не единственный, на его месте может быть и XML, и json, и просто абстрактный текст. А может и не быть вовсе, вся информация может содержаться в хедерах.

eoulianov: Нету абстрактного счастья в HTTP. Это действительно хорошо продуманный, гибкий протокол обмена стректуированными данными. Но в каждом конкретном случае тебе придётся общаться по нему с реальной железкой, в которой как-то настроен определённый HTTP сервер (а это-сложная в техническом смысле программа, зависящая от множества сервисов ОС), а он-то ждёт от тебя некоторых "опциональных" параметров, и фиг ты угадаешь, каких - кому-то жизнь не мила без user-agent а какой-то другой вообще не пришлёт тебе ответа без encoding или content-type. Серверы либо проигнорируют твои ключи, либо среагируют на их определенное сочетание. В обратку - ты получишь тоже набор опциональных ключей и контент, возможно из нескольких частей, возможно пожатый, и по-разному. Как только ты разберёшься с этой железкой, подберёшь формат пакета запроса, распарсишь ответ и оно заработает стабильно, и подумаешь чтобы написать "истинный общий модуль работы с HTTP", как жизнь не замедлит подкинуть surprise! - эта же железка обновится и в ней станет другая версия или конфигурация сервера, или по-другому переоформят URL запросов, или просто следующая железка попадётся и в ней: - в запросе появятся данные авторизации сессии - вместо HTTP настанет HTTPS - сервер захочет авторизоваться перед выдачей - потребуется эмулировать cookies - сервер проигнорирует ограничение по сжатому контенту, не поддержит твою кодировку, или кодировку с подстановками %% в URL пути И всё это будет на сугубо домашней железке на которую и в страшном сне не приснится заходить из интернета, как с этими верблюдами, и ничего, конечно, не настраивается. И поймешь тогда, что HTTP - он для браузеров, а вовсе не для домашней автоматизации придуман, и всё так же "по ситуации" будешь каждый раз с матом разбираться, как в этот раз дюна от невинного запроса по HTTP вешает на пару минут и твой контроллер и домашнюю сеть, а в другой раз - только сама встаёт.

gosha: Если речь о парсинге того, что изначально предназначено быть UI - то да, проще сразу застрелиться. Если речь о работе по документированному REST/SOAP/whatever_else API - то жить становится ГОРАЗДО легче

Вячеслав: Нагуглил не утешительный вариант решения: Убрать поле “Accept-Encoding: gzip” в запросе. А если его нет, то и убирать нечего (. Проверю еще раз свой запрос.

eoulianov: Тогда ничто не мешает написать [pre2]Accept-encoding: identity[/pre2] это, пожалуй, самый настойчивый вариант запроса от клиента чтобы не сжимало)

Вячеслав: Таки была фраза Accept-Encoding: gzip, deflate, Если не поможет просто убрать, то попробую Accept-encoding: identity Спасибо.

p.vladi: Ну а я что говорил, если сами сжатие простите, то его и получаете.. было очень много букф, а итог прост



полная версия страницы