Pull to refresh

Comments 32

=) "изучать основы HTTP протокола"
"какой POST запрос формирует браузер при отсылке заполненной веб-формы"
"Создаеть небольшой скрипт на PHP"
"в ОС Linux данный файл находится по адресу /ets/hosts"
"можно использовать снифер"

=) Обладая этими ^^^ знаниями, было бы гораздо проще проще - прочитать какую нить книжку...

Очень улыбнуло "Честно говоря, чтение мануалов никогда не входило в число моих сильных сторон, обычно на второй или третьей странице меня начинает клонить в сон, а после десятой бороться с этим желанием просто нет сил."

а потом фраза из разряда виндовых эникейщиков "а в Windows ищите сами, бог знает куда ушлые ребята из Мелкософта могли его засунуть." =)))))

PS на самом деле в твоей заметке гораздо больше само пеара нежели каких либо практических или теоретических знаний.

антиофтоп - ссылки в тему -
http://www.codeart.ru/2007/09/04/osnovy-http-protokola/ - между прочим та же статья что и выше.
http://ru.wikipedia.org/wiki/HTTP - в википедии про протокол
http://www.phpfaq.ru/na_tanke#headers - Просмотр обмена HTTP заголовками

и более информативные но на Англицком
http://www.cs.tut.fi/~jkorpela/http.html - Quick reference to HTTP headers
http://web-sniffer.net/ - View HTTP Request and Response Header - очень удобный веб тул
http://www.nextthing.org/archives/2005/08/07/fun-with-http-headers - Fun With HTTP Headers =) - думаю разработчики оценят
Извиняюсь, но начну с вопроса: "Ты читал мануал по HTTP протоколу?" А теперь представь, что ты новичок и пытаешься понять, что есть что. Читаешь читаешь... И нифига не понимаешь. Потому что не знаешь чего ищешь! А теперь представь ситуацию когда ты посмотрел HTTP запрос от одного браузера, потом от другого, заглянул в документацию и прочитал, что какой заголовок делает. Разница есть? Для меня была очень большая разница!
Что касается снифера, то изучение http протокола, сетевым анализатором, для новичка - издевательство над самим собой!
Что касается умных книжек, то их нужно читать! Но еще нужно уметь эксперементировать и заниматься самообучением.
Не понимаю проблему. Поиск таких вещёй я обычно начинаю со слова "RFC", нахожу требуемый документ, в вашем случае это будет запрос "RFC HTTP protocol", и гугл нас кидает первой ссылкой на http://www.w3.org/Protocols/rfc2616/rfc2… . Если с английским туго, то можно поискать перевод требуемого документа, и первый документ на запрос "RFC 2616 перевод" приводит нас на страницу с русским переводом этого протокола http://www.php.su/phphttp/docs/rfc2616/r… . Внимание, теперь вопрос, зачем это всё было городить?
Ответ на Ваш вопрос: "Внимание, теперь вопрос, зачем это всё было городить?" Вы дали в самом начале своего поста: "Не понимаю проблему.".

Думаю как только Вы поймете проблему, вопрос отпадет сам собой.
Я не понимаю проблему, которую вы для себя поставили, зачем городить огород, если вы таким образом не выучите полностью спецификации http протокола (есть не только post и get методы, посмотрите на название вашей темы, посмотрите на спецификации и укажите в процентах то, сколько вам удалось выучить от HTTP протокола). Вы не посмотрели, какие запросы будут, если например это всё идёт через proxy. Ваша ситуация здесь аналогична следующей: Как изучить способ заваривания маття, на примере чая в пакетиках.
Классно... Вот Вы всю жизнь разговариваете на русском, а всех слов не знаете, откройте толковый словарь и посмотрите какой процент слов Вы не знаете! Ведь кроме общеупотребительных выражений и слов, есть еще и специальные термины. Согласно Вашей логике, Вы не изучили язык, а значит и говорить на нем не можете! :-) Звучит бредово? Для меня Ваши слова о изучении спецификации на 100% такой же бред!

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

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

Очень интересно узнать, на сколько часто вы используете такие запросы как DELETE или PUT и т.д.?

И не надо намекать, что я плохо знаю спецификацию или не умею ей пользоваться. Как раз потому что умею и говорю, что для изучения HTTP протокола она не пригодна! Повторюсь спецификация - не учебник!
Признаюсь - я не читал, так как - это мне было не нужно для основной деятельности.
Однако поверхностно я знаком с вопросом.

"Потому что не знаешь чего ищешь!" - это как в той сказке - пойди - туда, не зная - куда и проч проч. Именно понимание задачи сокращает время на поиск решения.

"Что касается умных книжек, то их нужно читать!" - вот тут ты прав.

Однако очень глупо эксперементировать с тем в чём не понимаешь...
1 не сделаешь выводы
2 не осознаешь результаты

"Но еще нужно уметь эксперементировать и заниматься самообучением."
Читай, что написано выше ну или не читай и попробуй например пересобрать ядро.

Я привёл пример ссылок, которые в той или иной мере относятся к теме или подсказывают в какую сторону двигаться.

Если ты не понимаешь как искать и что искать зачем тогда вообще искать...
Скажи спасибо 2Frozik подскакавшему сакральное слово RFC.
"Однако поверхностно я знаком с вопросом." - это объясняет многое.

Я читал RFC, на которые так любите ссылаться! Причем читал внимательно, потратил на это ни один день. И могу сказать, что тогда мне это принесло мало пользы. RFC не описывает как реально(!) все работает, он описывает как это должно работать(!). Более того, 90% материала для новичка - китайская азбука , понимание конечно придет, но гораздо позже. А на первых порах лишняя информация только мешает.

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

Например мне, понадобилось очень много времени, чтобы просто научиться правильно читать RFC. Как любой инженерный документ, он требует определенных умений и знаний!

Все ссылки на RFC - просто понты, уверен, что тот же Frozik обучался по книжкам и статьям, или читал форумы. Повторюсь RFC - не пригоден для обучения чему-либо!
Это да, RFC как таблица умножения, видно что должно получиться, но умножать и делить в столбик по ней не научишьсяы.
По поводу ссылок:
http://www.cs.tut.fi/~jkorpela/http.html - Quick reference to HTTP headers - это обычная справка, как любая справка, она скорее будет полезна человеку с опытом нежели новичку.

http://web-sniffer.net/ - весьма ограниченый функционал, да и опять же полезен для человека с опытом, новичку ничего не объясняет, наоборот только подкидывает вопросов.

http://www.nextthing.org/archives/2005/0… - ну это уж точно не для новичков!

http://ru.wikipedia.org/wiki/HTTP - единственная ссылка, которая хоть как-то может быть полезна новичку

http://www.phpfaq.ru/na_tanke#headers - полезно, но не совсем в тему.

Отмечу, что тема заметки была "как изучить http протокол", а не "что такое http протокол".
Как правило (судя по форуму PHPClub) люди не испытывают проблем с интерпритацией заголовков полученных от сервера, зато испытывают проблем при необходимости отправить данные на сервер, просто не понимают какие должны быть заголовки. И в данной статье я как раз попытался рассказать, как узнать какие заголовки нужно отправить, причем не в аналитическом виде, а в том виде в каком они реально уходят на сервер. Обрати внимание на слово "УЗНАТЬ", я не перечисляю название заголовков и их значение, на эту тему написано много статей!
UFO just landed and posted this here
Не согласен, как раз таки учишься составлять сложные. Т.е. такие заголовки которые формируют реальные программы, а не простые GET или POST.
Плюс, те кто внимательно читал описание алгоритма, обратят внимание, что на экране отобразятся не только заголвки но и тело запроса (если речь идет о POST). Т.е. так можно понять, как отправляются файлы. Вообщем в итоге получаешь готовый запрос, даже думать как собрать все вмесе не надо.
UFO just landed and posted this here
В первом же комментарии к статье "генерация http запросов" служит ответом на вопрос, почему я предпочел использовать описанный выше метод.
Вот этот комментарий:

"Это неправильный запрос:
GET http://www.site.ru/news.html HTTP/1.0rn
Host: http://www.site.rurn

Правильно:
GET /news.html HTTP/1.1rn
Host: http://www.site.rurn
читайте RFC!"

Опечатки, ошибки автора и т.д. - проблема любой статьи. Как быть новичку, который не способен отличить где ошибка автора статьи, а где его собственная?

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

Я не отрицаю необходимость читать статьи, но при этом, уметь ставить эксперементы и самостоятельно получать ответы на свой вопросы, тоже очень важно!
Для цели, которую вы описали, на платформе Windows, отлично подходит программа http://www.proxomitron.ru/. Proxomitron - это прокси-сервер, который вы устанавливаете на своем компьютере, и, в браузере (rss-ридере, если он поддерживает прокси или др. программах), устанавливаете связь через него. Кроме приятных мелочей вроде вырезания ненужной рекламы, попапов, и прочих фильтров, Proxomitron умеет показывать HTTP-лог. Он покажет не только параметры отправленной формы, но и ответ сервера, все редиректы, коды ответов и т.д.
Вещь очень полезная, одним словом.
Не думаю, что для новичка - это удачный выбор. Хотя бы потому, что предназначение прокси-сервера вряд ли заключается в обучении HTTP-протоколу. :-)
Так и вы, имхо, HTTP протоколу учите косвенно.
И, вы хотите сказать, что новичку будет проще написать собственный HTTP-типа-сервер, который будет для него дампить HTTP Request, а так же, разобраться с /etc/hosts, и постоянно его передергивать... чем один раз поставить программу (2 мб) и настроить браузер, а потом просто смотреть HTTP-лог, когда это нужно ?!
Потом, HTTP - это не только Request, но еще и Response - в котором, кстати, может быть тоже много интересного и полезного.

А инструмент не новчика, имхо - это tcpdump.
Не видя лога этой программы сложно сказать, можно ли выудить из нее что-то полезное, но, честно говоря, я не видел не одной программы которая бы клала в лог http запрос в чистом виде. Проверить не могу, так как не работаю на Винде.

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

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

Насчет tcpdump-а. Может быть Вы расскажите, как его использовать в контексте статьи! Не знаю как Вас, а лично меня бесят теоретики, которые только языком чешут. Несмотря на то, что я регулярно использую tcpdump в работе, видимо я не все о нем знаю, и как получить http запрос с заголовками и телом даже не представляю. Так вот если Вы реально понимаете суть проблемы, а не трепите языком, сделайте милость хоть намекните как его использовать для вышеозначенных целей.
Пожалуйста, не злитесь. Простите, что я вообще влез в ваш топик. Я просто хотел рассказать об инструменте, не более того!

На счет tcpdump. Снимите tcpdump в файл. После этого, откройте dump в программе Ethereal (Windows), где настройте фильтр по HTTP трафику (Filter Expression). Далее, возьмите любой пакет из передачи и сделайте по нему "Follow TCP Stream". Ethereal построит отчет по этому запросу - как раз такой, что делает ваш скрипт.
Использовать такую комбинацию для целей, которые указали вы - это перебор, несомненно.

Еще раз, извините!
Вы меня тоже извините, за мою резкость. Но такое ощущение, что некоторые не понимают, чем отличается tcp от http и почему одним tcpdump-ом получить читабельный вывод нельзя! (По крайней мере я не знаю такого способа, более того уверен, что его нет!).
Вы же предлагаете использовать снифер, чтобы интерпретировать вывод tcpdump-а, причем в описанном Вами случае использование tcpdump мне кажется лишним. И как Вы уже сказали, такая цепочка уж явно не будет простой!
Такое ощущение, что народ начитался журнал "Хакер", а реально своей головой думать не хочет!
Именно по этому, в своем первом сообщении, я не говорил ничего про tcpdump, а рассказал про маленькую и крайне удобную программу, которая позволяет получать тело HTTP, не прибегая к написанию доп. скриптов и правки hosts.
Вы говорили, что сомневаетесь в том, что проксиметрон способен выдавать тело HTPTP запроса, и, наверно, подумали, что я просто хочу потрепать языком, и показать де, я умный, а автор - дурак. Это не так. Я подсказал более удобный, на мой взгляд, вариант получения тела HTTP-запроса.

Вот скриншот HTTP-лога проксиметрона, чтобы вы не сомневались в том, что я не просто треплю языком, начитавшись журнала "Хакер", а предлагаю рабочее решение: http://volosenkov.ru/img/proximetron.gif

И, наверно, уже надо заканчивать тему. Я уже понял, что вы упорный и своего мнения просто так не измените. Я же писал не для того, чтобы его менять, а чтобы, возможно, кому-то помочь, рассказав об удобном продукте.
файл hosts в Windows лежит по адресу:(к примеру диск С - системный)
C:\WINDOWS\system32\drivers\etc\hosts
А Ethereal - не решение? А толпы снифферов разного толка? А tcpdump?

Писать какие-то скрипты, вешать свой сервер на чужой домен - бред какой! Притом, если hosts переписать, не всегда и не везде достаточно вернуться в браузер и нажать кнопку. В зависимоcти от некторых условий браузер надо будет перезапустить.

Короче, мало того, что копипаст, так еще и предлагают с помощью молотка и автомобильного глушителя изучить повадки птиц. Бредятина, простите меня.
:-) Позволите процитировать вас в разделе "Юмор" на моем блоге?
Лучше всего изучать любой текстовый протокол с помощью telnet.
Извините, но может быть Вы расскажите как с помощью телнета обучиться отправлять, скажем, форму содержащую 5-6 полей на сервер, содержащую символы кирилицы. Очень интересно, как с помощью теленета, вы покажите новичкам связь, между тем какую страницу они видят перед собой в браузере и что при это реально ушло на сервер. Вообщем расскажите! Это будет отличная заметка.
Обучиться легко. Сначала нужно ознакомиться с основами протокола в любом доступном источнике (существует море статей, документация и Википедия). А затем уже изучать реакцию реальных серверов на самостоятельно составленные запросы. Только попрошу вас не рассказывать мне преимущества вашего подхода, т.к. подход у всех индивидуальный, и ваша заметка, базусловно, кому-нибудь да поможет.
:-) Не обижайтесь, но лично Вы для изучения какого протокола использовали telnet (полноценного изучения, с перебором различных заголовков, анализом выдаваемого результата и т.д.)? И сколько у Вас на это времени ушло!?

Подозреваю, что если мы начнем развивать эту тему, то окажется, что вы используете телнет эпизодически, если вообще используете.
Обязательно обижусь, как же иначе. Ознакамливался с HTTP, FTP и XMPP. Без секундомера только. Вы, надеюсь, не будете обижаться.

А развивать эту тему я не буду ;) И да, разумеется, я использую его эпизодически, потому что сайты удобней смотреть связкой wget и html2text.

Откуда у вас такое стремление мне что-то доказать? Я вам верю, верю. Честно :)
Вы правы, пора закрывать этот бессмысленный разговор :-)
Есть у меня одна черта, упрямство называется, вот поэтому и спорю до потери пульса и понимания темы спора! :-)
Sign up to leave a comment.

Articles