|
List Info
Thread: BUG: bad parse of full URL in request?
|
|
| BUG: bad parse of full URL in request? |
|
2006-05-03 23:10:35 |
|
Hi all,
This is my first mail to cherokee mailing lists, so I hope I send it to the correct one.
I've been browsing source code from svn repository and a I've seen something strange (at least strange for me). In file
header.c, function parse_request_first_line (lines 443 - 458) it checks if the resource requested is a full URL, and if it is, it looks for a '/' for getting the path of the resource in the server. But what if we do:
$ telnet www.alobbs.com 80
...
GET
http://www.alobbs.com HTTP/1.1
Host: www.alobbs.com ;
??
We get:
HTTP/1.1 400 Bad Request
...
And what if we do:
$ telnet
www.alobbs.com 80
...
GET http://www.alobbs.com/
HTTP/1.1
Host: www.alobbs.com
??
In this case, we get:
HTTP/1.1 200 OK
...
I think the response of the first example is not correct, because it should consider the situation where the request don't have that '/' the code is looking for because the main page is being requested. Shouldn't cherokee return a 3XX code?
Of course, I can be wrong, I'm only a student with few knowledge about web servers. If so, I'm sorry.
I'm sorry about my poor english too.
Ouch!! I almost forget that:
Cherokee version: "Server: Cherokee/0.5.3 (UNIX)"
And I think the same problem appears in svn version.
Greetings,
Diego
-----------------------------------------------
[Spanish Version]
Por si no se me entiende y sabiendo que Álvaro (y algún otro desarrollador/colaborador/usuario de la lista) es español/latinoamericano, intentaré explicarme en castellano:
He estado ojeando el código del repositorio svn (cherokee/trunk/cherokee) y me ha parecido extraño que en la función parse_request_first_line del fichero header.c (lineas 443 - 458), al comprobar si se trata de una URL completa se busca una '/' sin más (aparte del http://). Es decir, sin considerar el caso de que se trate de una petición de la página principal, como pongo en el ejemplo primero:
$ telnet www.alobbs.com 80
...
GET http://www.alobbs.com HTTP/1.1
Host: www.alobbs.com ;
HTTP/1.1 400 Bad Request
...
Al ver que si pongo la barra devuelve un código de éxito:
$ telnet www.alobbs.com 80
...
GET http://www.alobbs.com/ HTTP/1.1
Host: www.alobbs.com
HTTP/1.1 200 OK
...
me ha "confirmado"; mis sospechas de que puede tratarse de un error.
Pero como también he dicho, no soy ningún gurú del tema, ni mucho menos, por ese motivo mis disculpas si estoy equivocado o estoy diciendo alguna tontería.
Supongo que será importante saber la versión del servidor en el que lo he probado, pero eso Álvaro lo sabrá bien. Lo he probado con
www.alobbs.com porque no tengo ningún cherokee a mano y sabía que ahí habría uno 
Sin más,
Saludos,
Diego
PS: cualquier cosa que haya hecho o dicho mal, agradecería corrección 
PS2: he estado mirando por el archivo de mensajes viejos de la lista y no he encontrado nada sobre el tema, espero que no se trate de algo repetido. Lo que sí he encontrado es que se debe escribir en inglés, espero que esta versión en español no sea una molestia.
|
| BUG: bad parse of full URL in request? |
|
2006-05-04 09:57:17 |
Hi,
> This is my first mail to cherokee mailing lists, so I
hope I send it
> to the correct one.
Welcome Diego ;)
> I've been browsing source code from svn repository and
a I've seen
> something strange (at least strange for me). In file
header.c,
> function parse_request_first_line (lines 443 - 458) it
checks if the
> resource requested is a full URL, and if it is, it
looks for a '/'
> for getting the path of the resource in the server. But
what if we
> do:
>
> $ telnet www.alobbs.com 80
> GET http://www.alobbs.com
HTTP/1.1
> Host: www.alobbs.com
>
> HTTP/1.1 400 Bad Request
> ...
This is a known unsupported corner case. Let me explain
the reasons:
- In first place, almost all the request that a Web
Server receives
don't include the URI in the request, something like
this:
GET / HTTP/1.1
Host: www.alobbs.com
so, there is no need of parsing the URL, simple because the
request and the Host header entry let the server know
everything
it needs. I guess 99% of the request a common server
receives are
not using full URLs as request.
- It only happen when the request doesn't request any
object.
I would be happy to improve the support of this corner
case, but it
would need some quite big changes in the header.c code,
and probably
it would slow down a little bit the current code, so I
think it
doesn't worth supporting the case.
Anyway, it someone finds out a way in which we can support
it with
messing up the code or slowing down the header parsing
I'll more
than happy to apply the patch.
> Of course, I can be wrong, I'm only a student with few
knowledge
> about web servers. If so, I'm sorry. I'm sorry about
my poor
> english too.
You were right Diego. There is an explanation for the
issue though.
> Ouch!! I almost forget that: Cherokee version:
"Server:
> Cherokee/0.5.3 (UNIX)" And I think the same
problem appears in svn
> version.
The SVN trunk version is currently upside down. I have
been working
in some HUGE changes for Cherokee 0.6, so we will need to
start
working with pre-releases within a month or two in order
to
stabilize all the new code
--
Greetings, alo.
_______________________________________________
Cherokee mailing list
Cherokee 0x50.org
http://www.0x50.org/cgi-bin/mailman/listinfo/cherokee
|
|
| BUG: bad parse of full URL in request? |
|
2006-05-08 22:43:56 |
|
2006/5/4, Alvaro Lopez Ortega <sun.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">alvarosun.com>:
This is a known unsupported corner case. Let me explain the reasons:
; - In first place, almost all the request that a Web Server receives
; don't include the URI in the request, something like this:
; GET / HTTP/1.1
; Host: www.alobbs.com
so, there is no need of parsing the URL, simple because the
; request and the Host header entry let the server know everything
it needs. I guess 99% of the request a common server receives are
; not using full URLs as request.
; - It only happen when the request doesn't request any object.
Of course, I know it is not frequent ( I guess it is less than 1%,
0.001% ? ). The reason of my first mail is that I prefer things working well in 100% of cases :-P
I would be happy to improve the support of this corner case, but it
would need some quite big changes in the header.c code, and probably
it would slow down a little bit the current code, so I think it
doesn't worth supporting the case.
Anyway, it someone finds out a way in which we can support it with
; messing up the code or slowing down the header parsing I'll more
; than happy to apply the patch. I have no time for thinking about it (exams but I'll do it. In a quick look at the code I only guess two ways for doing it, and I don't like any of them.
The SVN trunk version is currently upside down. I have been working
in some HUGE changes for Cherokee
0.6, so we will need to start
working with pre-releases within a month or two in order to
stabilize all the new code
Ok
Greetings,
Diego
|
[1-3]
|
|