Sobre definición de errores

2 views
Skip to first unread message

Kume66

unread,
Dec 4, 2009, 6:47:43 AM12/4/09
to SEMINARIO DE REDES - TP FINAL
Propongo que los errores del lado cliente sean estos:
nota: con * me refiero a las que para mi son a nivel de aplicación y
no RFC

"406" Error de sintaxis
"407" Error largo de nombre, password, archivo (*)
"408" Error disco lleno (Por si pido un archivo y no queda espacio en
el disco rigido local.)
"409" Error versión incompatible (*)

Del lado del servidor:

"401" (PASS incorrecto)
"402" (archivo no encontrado)
"403" (agotado espacio en disco)
"404" (sin permiso en el servidor para escribir)
"405" (Versión incompatible) (*)

Puse "" a los números porque los trabajamos como string, para que no
se confunda con el numero en si.

Romeo César

unread,
Dec 4, 2009, 7:14:44 AM12/4/09
to seminario-de-re...@googlegroups.com
Kume66:
me parece que ayer habia dicho que los errores locales iban a ser de la 3 centena ( 300,301,302).
Otra sugerencia: el 406 y  407 que propones no se pueden juntar en un solo error.
¿cual es la diferencia entre el 409 y el 405?
volviendo a la distincion entre locales y externos: tendriamos que hacer que tengan relacion los numeros de los errores locales y externos:
ej: "303"error disco lleno (local)
     "403" error disco lleno(externo)

romeo

Kume66

unread,
Dec 4, 2009, 7:16:50 AM12/4/09
to SEMINARIO DE REDES - TP FINAL
Me olvide de comentar algo sobre el timeout.
Debido a que no tenemos el round-trip time, propongo que lo fijemos en
5 segundo, desde el momento en que el
cliente envía la petición.

Copiando un poco la RFC de HTTP1.1 propongo identificar los errores
del server del 500 en adelante,y del cliente del 400 en adelante
por esto corrijo lo anterior.

Otros errores del lado del cliente:
"401" Error de sintaxis
"402" Error largo de nombre, password, archivo (*)
"403" Error disco lleno (Por si pido un archivo y no queda espacio en
el disco rigido local.)
"404" Error versión incompatible (*)
"405" No implementado (por si pasan una petición diferente a Get o
Put)
"406" Request timeout

Del lado del server:

"501" (PASS incorrecto)
"502" (archivo no encontrado)
"503" (agotado espacio en disco)
"504" (sin permiso en el servidor para escribir)
"505" No implementado( por si pasan una petición diferente a Get o
Put)
"506" Versión no soportada


Martin Eugenio Morales

unread,
Dec 4, 2009, 9:22:54 AM12/4/09
to seminario-de-re...@googlegroups.com
Vamoooooos que arrancamooos!!
Bueno, con respecto a los errores, hago algunas aclaraciones para ver si entendi bien:

errores del lado del cliente:

"401" Error de sintaxis (refiere a error en el formato del requerimiento)


"402" Error largo de nombre, password, archivo  (*)
"403" Error disco lleno  (Por si pido un archivo y no queda espacio en
el disco rigido local.)

"404" Error versión incompatible (*) (esta no se si va del lado del cliente, no va solo del lado del servidor?)
"405" Peticion No implementada (por si pasan una petición diferente a Get o Put)
"406" Request timeout
Agrego:
"407" No se establecio la conexion, o no puede establecerse la conexion
"408" No se puede encontrar el servidor


Del lado del server:

"501" (USR y/o PASS incorrecto)


"502" (archivo no encontrado)
"503" (agotado espacio en disco)
"504" (sin permiso en el servidor para escribir)

"505" Peticion No implementada ( por si pasan una petición diferente a Get o Put)
"506" Versión no soportada


Preguntas: 405 y 505: van en ambos lados? o solo en el server?
                 esta el codigo "200" que habiamos definido como info OK, de que lado iria?
                 timeout: 5 seg? o un poco mas? por las dudas nomas que se yo 

vamos a cerrar estas cosas y seguimos con las demas.
Si el presidente me da el OK las subo al RFC

saludos


----- Mensaje original ----
De: Kume66 <mon...@gmail.com>
Para: SEMINARIO DE REDES - TP FINAL <seminario-de-re...@googlegroups.com>
Enviado: viernes, 4 de diciembre, 2009 9:16:50
Asunto: Re: Sobre definición de errores

Del lado del server:


Yahoo! Cocina

Encontra las mejores recetas con Yahoo! Cocina.


http://ar.mujer.yahoo.com/cocina/

Kume66

unread,
Dec 4, 2009, 9:31:21 AM12/4/09
to SEMINARIO DE REDES - TP FINAL
En cuanto a 405 y 505
Para mi va de los dos lados,, pero es de pura intuición.

En cuanto al status 200, propongo armar otro debate sobre las
respuestas..
ya que tengo algunas dudas...Si nadie lo abre empiezo uno yo más tarde

saludos

Ramiro

unread,
Dec 5, 2009, 5:16:42 PM12/5/09
to SEMINARIO DE REDES - TP FINAL
Deberiamos especificar el formato con el que van a viajar los errores.
De la misma forma en que especificamos el GET y el PUT.
Que es parece si hacemos que la respuesta tenga el mismo formato:
algo asi como:

RESPUESTA (enter)
"codigo" (enter)


o si quieren en inglés:

ANSWER (enter)
"codigo" (enter)

Martin Eugenio Morales

unread,
Dec 5, 2009, 8:26:07 PM12/5/09
to seminario-de-re...@googlegroups.com
1) en RESPUESTA iria ERROR o OK por ejemplo? u otras palabras pero esa es la idea? me parece bien en si la forma que propones

2) copio nuevamente los errores que tenemos por ahora para ver si agregamos o sacamos alguno asi tambien los definimos 

Códigos de ERROR del lado del Cliente:
401 Error: sintaxis. (Refiere a error en el formato de la solicitud)
402 Error: largo de usuario, contraseña o archivo incorrecto. (Si se presentan caracteres inválidos)  
403 Error: disco lleno. (Por si pido un archivo y no queda espacio en el disco rígido local.)
404 Error: versión incompatible
405 Error: Petición No implementada (Si se envía una petición diferente a Get o Put)
406 Error: Vencido el tiempo de solicitud
407 Error: No puede establecerse la conexión
408 Error: No se puede encontrar el servidor  
 
Códigos de error del lado del Servidor:
501 Error: usuario o contraseña incorrecto
502 Error: archivo no encontrado
503 Error: agotado espacio en disco
504 Error: sin permiso para escribir
505 Error: Petición No implementada ( por si pasan una petición diferente a Get o Put)
506 Error: Versión no soportada
3) tema timeout por si no se puede conectar el servidor u algun otro caso, cuanto definimos?

4) como definimos al final el numero de version? 1.1, 1.2, 1.2, etc o 1, 2, 3?

5) que mas faltaria agregar al RFC?

Respondamos en orden o con los numeros asi lo hacemos mas ordenado

saludos 


----- Mensaje original ----
De: Ramiro <ninja...@gmail.com>


Para: SEMINARIO DE REDES - TP FINAL <seminario-de-re...@googlegroups.com>

Enviado: sábado, 5 de diciembre, 2009 19:16:42
Asunto: Re: Sobre definición de errores y timeout

RESPUESTA  (enter)
"codigo" (enter)

ANSWER  (enter)
"codigo" (enter)

Yahoo! Cocina

Ramiro Alonso

unread,
Dec 6, 2009, 11:00:11 AM12/6/09
to seminario-de-re...@googlegroups.com
Si estaba pensando en el mismo formato que los PUTs o GETs.
Nose que conviene mas, quetenga 2 respuestas posibles (error, ok) o que el texto de la respuesta sea unico y despues identificamos la misma con el codigo.
Si o si vamos a tener que hacer una identificacion con el codigo, dado que hay muchas respuestas posibles. Por eso pensaba que la respuesa tendria que tener un formato unico, sea un ERROR o sea un OK, y con el codigo la aplicacion puede identificar el tipo de respuesta es.

Por eso propondria el siguiente formato:

ANSWER<-l     // "<-l" significa enter
"codigo"<-l       //El codigo es un numero de 3 digitos
<-l                   // Una linea en blanco, igual que en los otros mensajes



EJEMPLO, para un error de contraseña


----------------------------------------------------------------

ANSWER<-l     
501<-l       
<-l 

----------------------------------------------------------------


Habria que ver si es necesario agregar mas informacion en la respuesta. Es necesario poner el numero de version en la respuesta???
Les parece que lo suba como requisito para la proxima RFC?

Saludos,
Ramiro





2009/12/5 Martin Eugenio Morales <morales_ma...@yahoo.com.ar>

Matias

unread,
Dec 6, 2009, 6:12:23 PM12/6/09
to SEMINARIO DE REDES - TP FINAL
Creo que ya habiamos definido el tipo de respuesta como

STATUS XXX"\n"

Donde xxx era el codigo y "\n" el enter

Con respecto a los timeouts es requisito para el TP ?? No queda mucho
tiempo, para mi habria que ir cerrando temas y no crear nuevas
funcionalidades.

Las respuestas del servidor debe ser sencillas, como dijo pablo no
conviene tener muchos msg de ida y de vuelta. Habria que determinar en
clase (por aca me parece muy complicado) el flujo de mensajes para los
dos tipos de funciones, GET y PUT.
> 2009/12/5 Martin Eugenio Morales <morales_martineuge...@yahoo.com.ar>
> > De: Ramiro <ninjaram...@gmail.com>
Reply all
Reply to author
Forward
0 new messages