форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"проблема с HTTP POST"
Сообщение от vvk on 15-Фев-03, 11:52  (MSK)
посылаю пост приготовленный таким образом: через сокет. на сервере имею в логах: 192.168.1.2 - - [15/Feb/2003:11:44:12 +0300] "POST /client/receiver HTTP/1.1" 400 304 в ошибках: [Sat Feb 15 11:44:12 2003] [error] [client 192.168.1.2] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /client/receiver в чем ошибка. есть правильный клиент, при запуске которого в логах вижу: 192.168.1.3 - - [15/Feb/2003:11:41:56 +0300] "POST /client/receiver HTTP/1.1" 200 12 разница только в этих циферках (200,12). Что это? что я неправильно делаю?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "RE: проблема с HTTP POST"
Сообщение от vvk on 15-Фев-03, 11:55  (MSK)
приготовленный таким образом: datalenght = sprintf( databuf, "POST /client/receiver HTTP/1.1\r\n" ); rfc смотрел... но как говориться, смотрю в книгу, вижу фигу :) вроде все как надо, и строка POST правильная
	Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "RE: проблема с HTTP POST"
Сообщение от vnp on 16-Фев-03, 00:08  (MSK)
>посылаю пост приготовленный таким образом: > >через сокет. на сервере имею в логах: >192.168.1.2 - - [15/Feb/2003:11:44:12 +0300] "POST /client/receiver HTTP/1.1" 400 304 >в ошибках: >[Sat Feb 15 11:44:12 2003] [error] [client 192.168.1.2] client sent HTTP/1.1 request >without hostname (see RFC2616 section 14.23): /client/receiver Он же английским языком говорит: HTTP/1.1 request without hostname На уровне 1.1 обязателен заголовок "Host: ..." (В rfc сказано: A client MUST include a Host header field in all HTTP/1.1 request) >в чем ошибка. есть правильный клиент, при запуске которого в логах вижу: > >192.168.1.3 - - [15/Feb/2003:11:41:56 +0300] "POST /client/receiver HTTP/1.1" 200 12 > >разница только в этих циферках (200,12). Что это? что я неправильно делаю? >
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "RE: проблема с HTTP POST"
	Сообщение от vvk on 17-Фев-03, 10:09  (MSK)
	спасибо! действительно проглядел. но вот дальше продвинулся, но все равно не работает. теперь дамп того, что посылается выглядит так: POST /client/receiver HTTP/1.1 Host: 192.168.1.3 Content-Type: application/x-www-form-urlencoded Content-Type: multipart/form-data; boundary=MY_SEPARATOR_STRING --MY_SEPARATOR_STRING Content-Disposition: form-data; name="status" C_LOGIN --MY_SEPARATOR_STRING Content-Disposition: form-data; name="company" companyname --MY_SEPARATOR_STRING Content-Disposition: form-data; name="user" username --MY_SEPARATOR_STRING Content-Disposition: form-data; name="password" passwordvalue --MY_SEPARATOR_STRING-- все вроде бы правильно, но на этот раз в логах 192.168.1.2 - - [17/Feb/2003:09:58:48 +0300] "POST /client/receiver HTTP/1.1" 200 12 192.168.1.2 - - [17/Feb/2003:09:58:48 +0300] "--MY_SEPARATOR_STRING" 501 314 а в ошибках: [Mon Feb 17 09:58:48 2003] [error] [client 192.168.1.2] Invalid method in request --MY_SEPARATOR_STRING какой же инвалид, если это boundary (причем объяалял боундари и так, и в кавычках). Что скажешь?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "RE: проблема с HTTP POST"
	Сообщение от vnp on 17-Фев-03, 11:07  (MSK)
	>спасибо! действительно проглядел. но вот дальше продвинулся, но все равно не работает. >теперь дамп того, что посылается выглядит так: > >POST /client/receiver HTTP/1.1 >Host: 192.168.1.3 >Content-Type: application/x-www-form-urlencoded >Content-Type: multipart/form-data; boundary=MY_SEPARATOR_STRING > >--MY_SEPARATOR_STRING >Content-Disposition: form-data; name="status" > >C_LOGIN >--MY_SEPARATOR_STRING >Content-Disposition: form-data; name="company" > >companyname >--MY_SEPARATOR_STRING >Content-Disposition: form-data; name="user" > >username >--MY_SEPARATOR_STRING >Content-Disposition: form-data; name="password" > >passwordvalue >--MY_SEPARATOR_STRING-- > >все вроде бы правильно, но на этот раз в логах > >192.168.1.2 - - [17/Feb/2003:09:58:48 +0300] "POST /client/receiver HTTP/1.1" 200 12 >192.168.1.2 - - [17/Feb/2003:09:58:48 +0300] "--MY_SEPARATOR_STRING" 501 314 > >а в ошибках: >[Mon Feb 17 09:58:48 2003] [error] [client 192.168.1.2] Invalid method in request >--MY_SEPARATOR_STRING > >какой же инвалид, если это boundary (причем объяалял боундари и так, и >в кавычках). Что скажешь? Тут несколько ошибок. Во-первых, не определен конец сообщения. Нужен или Content-Length или Transfer-Encoding: chunked (со всеми вытекающими чанками). Подозреваю, что сервер, не найдя ни того ни другого, счел длину посылки равной нулю, и решил, что --MY_SEPARATOR_STRING есть метод следующего в pipeline запроса. NB: multipart допускает пролог и эпилог (перед первым boubdary и после заключительного), поэтому надеяться, что сервер станет опираться на boundaries в поисках конца запроса, нельзя. Во вторых, сервер был явно смущен двумя заголовками Content-Type и, скорее всего, проигнорировал второй. Если убрать первый (который, к тому же, врет), сразу полегчает. Наконец (это не ошибка, просто странно смотрится), multipart в данном контексте -- явный перебор. Успехов.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "RE: проблема с HTTP POST"
	Сообщение от vvk on 17-Фев-03, 11:15  (MSK)
	>Тут несколько ошибок. Во-первых, не определен конец сообщения. Нужен >или Content-Length или Transfer-Encoding: chunked (со всеми вытекающими >чанками). Подозреваю, что сервер, не найдя ни того ни другого, счел >длину посылки равной нулю, и решил, что --MY_SEPARATOR_STRING есть метод >следующего в pipeline запроса. >NB: multipart допускает пролог и эпилог (перед первым boubdary и после >заключительного), поэтому надеяться, что сервер станет опираться на >boundaries в поисках конца запроса, нельзя. >Во вторых, сервер был явно смущен двумя заголовками Content-Type и, >скорее всего, проигнорировал второй. Если убрать первый (который, к тому >же, врет), сразу полегчает. > >Наконец (это не ошибка, просто странно смотрится), multipart в данном >контексте -- явный перебор. > >Успехов. ок. спасибо буду исправлять. видимо действительно проблема в том, что я не указал Content-length... ответ такой он мне дает: HTTP/1.1 200 OK Date: Mon, 17 Feb 2003 08:01:22 GMT Server: Apache/2.0.44 (Win32) Content-Length: 12 Content-Type: text/html; charset=ISO-8859-1 status=S_OK <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>501 Method Not Implemented</title> </head><body> <h1>Method Not Implemented</h1> <p>--MY_SEPARATOR_STRING to /index.html.en not supported.<br /> </p> <hr /> <address>Apache/2.0.44 (Win32) Server at 192.168.1.2 Port 80</address> </body></html> что свидетельствует о том, что дейсвтвительно он решил, что это пошел уже второй запрос. Так что буду пытаться посчитать правильно длину.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "RE: проблема с HTTP POST"
	Сообщение от vvk on 17-Фев-03, 12:32  (MSK)
	хмм... теперь запрос выглядит так: POST /client/receiver HTTP/1.1 Host: 192.168.1.3 Content-length: 190 Content-Type: application/x-www-form-urlencoded Content-Type: multipart/form-data; boundary="MY_SEPARATOR_STRING" --MY_SEPARATOR_STRING Content-Disposition: form-data; name="status" C_LOGIN --MY_SEPARATOR_STRING Content-Disposition: form-data; name="company" companyname --MY_SEPARATOR_STRING-- ответ: HTTP/1.1 200 OK Date: Mon, 17 Feb 2003 09:19:19 GMT Server: Apache/2.0.44 (Win32) Transfer-Encoding: chunked Content-Type: text/html; charset=ISO-8859-1 c status=S_OK 0 Но длина сообщения на самом деле 194... потом ответа почему то приходиться ждать очень долго. такое ощущение, что сервер не догадывается, что все уже отослано и ждет чего то. при чем если написать реальную длину (194) то ответа вообще фиг дождешся. (все стоит на моих локальных машинах и если вдруг ошибка тогда вообще сразу отвечает). Кроме того почемуто мне "чанкед" стал отвечать, хотя по началу content-length указывал. короче что то я в полной растерянности. може на libwww поближе посмотреть.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "RE: проблема с HTTP POST"
	Сообщение от vvk on 17-Фев-03, 12:42  (MSK)
	сорри, в запросе Content-Type: application/x-www-form-urlencoded убрал. без него гораздо лучше :) но вот проблема с длиной контента и временем ответа остается. подскажи, плиз.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "RE: проблема с HTTP POST"
	Сообщение от vnp on 17-Фев-03, 21:52  (MSK)
	>хмм... теперь запрос выглядит так: > >POST /client/receiver HTTP/1.1 >Host: 192.168.1.3 >Content-length: 190 >Content-Type: application/x-www-form-urlencoded >Content-Type: multipart/form-data; boundary="MY_SEPARATOR_STRING" > >--MY_SEPARATOR_STRING >Content-Disposition: form-data; name="status" > >C_LOGIN >--MY_SEPARATOR_STRING >Content-Disposition: form-data; name="company" > >companyname >--MY_SEPARATOR_STRING-- > >ответ: > >HTTP/1.1 200 OK >Date: Mon, 17 Feb 2003 09:19:19 GMT >Server: Apache/2.0.44 (Win32) >Transfer-Encoding: chunked >Content-Type: text/html; charset=ISO-8859-1 > >c >status=S_OK > >0 > >Но длина сообщения на самом деле 194... >потом ответа почему то приходиться ждать очень долго. такое ощущение, что сервер >не догадывается, что все уже отослано и ждет чего то. при >чем если написать реальную длину (194) то ответа вообще фиг дождешся. >(все стоит на моих локальных машинах и если вдруг ошибка тогда >вообще сразу отвечает). >Кроме того почемуто мне "чанкед" стал отвечать, хотя по началу content-length указывал. Это -- добрый знак. В смысле, сервер верит, что клиент понимает 1.1. Похоже, что с протоколом разобрались и проблема переместилась пониже. Буферизация в сокете? Навороты с CR/LF? Код надо смотреть, однако. >короче что то я в полной растерянности. може на libwww поближе посмотреть. >
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "RE: проблема с HTTP POST"
	Сообщение от vvk on 18-Фев-03, 20:09  (MSK)
	последняя строка формируется так: datalength = sprintf( databuf, "\r\n--%s--\r\n", BOUNDARY ); где BOUNDARY = MY_SEPARATOR_STRING и судя по тому, что в случае ошибки сервер отвечает моментально, скорее всего тормозит именно сервер, как будто ожидая еще чего то. Что не так в моей строке? как лучше ее сформировать?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "RE: проблема с HTTP POST"
	Сообщение от vnp on 19-Фев-03, 03:12  (MSK)
	>последняя строка формируется так: > >datalength = sprintf( databuf, "\r\n--%s--\r\n", BOUNDARY ); >где BOUNDARY = MY_SEPARATOR_STRING > >и судя по тому, что в случае ошибки сервер отвечает моментально, скорее >всего тормозит именно сервер, как будто ожидая еще чего то. Что >не так в моей строке? как лучше ее сформировать? В строке все чудно. Ваш запрос выглядит практически правильным (для полного счастья не хватает самой распоследней CRLF в конце, но на это мало кто обращает внимание). Я испытал его пользуясь своим тестовым клиентом на элементарном скрипте, и все сработало на ура -- при том, что Content-Length был 194. Вообще, согласно Вашим симптомам, сервер, похоже, вне подозрений. Основное неизвестное теперь -- скрипт.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "RE: проблема с HTTP POST"
	Сообщение от vvk on 19-Фев-03, 09:43  (MSK)
	да я тоже вроде на элементарном скрипте тестирую (я надеюсь что я правильно понял, что такое скрипт :)  Там четыре строки на perl-e. у меня его правда под рукой сейчас нет. Можешь скинуть скрипт, на котором ты проверял? чтобы я мог проверить и либо искать ошибку в моем клиенте, либо быть уверенным, что он работает хорошо и не париться. >>последняя строка формируется так: >> >>datalength = sprintf( databuf, "\r\n--%s--\r\n", BOUNDARY ); >>где BOUNDARY = MY_SEPARATOR_STRING >> >>и судя по тому, что в случае ошибки сервер отвечает моментально, скорее >>всего тормозит именно сервер, как будто ожидая еще чего то. Что >>не так в моей строке? как лучше ее сформировать? > >В строке все чудно. Ваш запрос выглядит практически правильным (для >полного счастья не хватает самой распоследней CRLF в конце, но на это > >мало кто обращает внимание). Я испытал его пользуясь своим тестовым >клиентом на элементарном скрипте, и все сработало на ура -- при том, > >что Content-Length был 194. Вообще, согласно Вашим симптомам, сервер, >похоже, вне подозрений. Основное неизвестное теперь -- скрипт.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "RE: проблема с HTTP POST"
	Сообщение от vnp on 19-Фев-03, 21:25  (MSK)
	>да я тоже вроде на элементарном скрипте тестирую (я надеюсь что я >правильно понял, что такое скрипт :)  Там четыре строки на >perl-e. у меня его правда под рукой сейчас нет. >Можешь скинуть скрипт, на котором ты проверял? чтобы я мог проверить >и либо искать ошибку в моем клиенте, либо быть уверенным, что >он работает хорошо и не париться. <?php while(list($key, $value) = each($_POST)) echo "$key = $value\n" ?> >>что Content-Length был 194. Вообще, согласно Вашим симптомам, сервер, >>похоже, вне подозрений. Основное неизвестное теперь -- скрипт. По зрелом размышлении, может, все-таки ваш клиент не до конца отправляет?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	13. "RE: проблема с HTTP POST"
	Сообщение от vvk on 19-Фев-03, 21:59  (MSK)
	>По зрелом размышлении, может, все-таки ваш клиент не до конца отправляет? а как определить? в том то и дело, что все. данные приходят правильные. читаю и пишу данные таким кодом, взятым из faq-а: /* This is just like the read() system call, accept that it will make    sure that all your data goes through the socket. */ int sock_read(int sockfd, char *buf, size_t count) {   size_t bytes_read = 0;   int this_read;   while (bytes_read < count) {     do       this_read = read(sockfd, buf, count - bytes_read);     while ( (this_read < 0) && (errno == EINTR) );     if (this_read < 0)       return this_read;     else if (this_read == 0)       return bytes_read;     bytes_read += this_read;     buf += this_read;   }   return count; } /* This is just like the write() system call, accept that it will    make sure that all data is transmitted. */ int sock_write(int sockfd, const char *buf, int count) {   size_t bytes_sent = 0;   int this_write;   while (bytes_sent < count) {     do       this_write = write(sockfd, buf, count - bytes_sent);     while ( (this_write < 0) && (errno == EINTR) );     if (this_write <= 0)       return this_write;     bytes_sent += this_write;     buf += this_write;   }   return count; } единственно, что когда я читаю, я не знаю,сколько прийдет, поэтому делаю так: char buf[2048]; int reslen = sock_read(sock, buf, sizeof(buf)); но я так думаю, это не должно повлиять на скорость. у меня скрипт такой на сервере: #!/perl/bin/perl #$!=1; use CGI qw/:standard/; use Data::Dumper; print header(); #foreach $i (keys %ENV) { #  print "ENV { $i } = " . $ENV{$i} . "<BR>\n"; #} open (TRACE, ">>trace" ) || die "Error opening TRACE $!"; my $q = new CGI(); print TRACE Dumper( $q ); close (TRACE); print "status=S_OK\n";
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	14. "RE: проблема с HTTP POST"
	Сообщение от vnp on 19-Фев-03, 22:50  (MSK)
	>единственно, что когда я читаю, я не знаю,сколько прийдет, поэтому делаю так: > >char buf[2048]; >int reslen = sock_read(sock, buf, sizeof(buf)); > >но я так думаю, это не должно повлиять на скорость. О! Оно и есть. sock_read пытается вычитать все 2048 байт. То, что сервер прислал, прочитывается моментально. Далее sock_read висит в read, который вернется (с результатом 0) только когда сокет закроется. Сервер же, (благодаря HTTP/1.1) активно его закрывать не будет, и закроется он лишь по таймауту (а он бывает до 15 минут...). В случае ошибки, однако, сервер закроет его сразу (дескать, знать вас за это не знаю), что вы и наблюдали. Ответ на уровне 1.1 надо читать очень аккуратно: с помощью poll/select, обязательно разбирая заголовки (особенно Content-Length, Transfer-Encoding и Connection).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	15. "RE: проблема с HTTP POST"
	Сообщение от vvk on 19-Фев-03, 23:11  (MSK)
	>О! Оно и есть. >sock_read пытается вычитать все 2048 байт. То, что сервер прислал, >прочитывается моментально. Далее sock_read висит в read, который вернется >(с результатом 0) только когда сокет закроется. Сервер же, (благодаря >HTTP/1.1) активно его закрывать не будет, и закроется он лишь по >таймауту (а он бывает до 15 минут...). В случае ошибки, однако, сервер > >закроет его сразу (дескать, знать вас за это не знаю), что вы >и >наблюдали. > >Ответ на уровне 1.1 надо читать очень аккуратно: с помощью poll/select, >обязательно разбирая заголовки (особенно Content-Length, Transfer-Encoding >и Connection). Век живи - век учись! хмм... буду копать в сторону poll/select... хотя смутно представляю, что это такое. Мне бы конечно было бы проще выкачать все что сказали и потом уж разбираться.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

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