PreguntasHTTPdeexmenes

Qutiposdesistemasintermediospodemosencontrarentreunclienteyunservidor web? Proxy: Sistema intermedio que acta en nombre del cliente presentando las solicitudes al servidor.Actacomoservidorcuandotrataconelclienteycomoclientecuandotrataconel servidor. Gateway:Sistemaintermedioqueesunservidorrespectoalclienteyactacomosifuerael servidor original. Acta en nombre de servidores que no son capaces de comunicarse directamenteconelcliente. Tnel: Sistema intermedio que no realiza operaciones con los mensajes. Es un punto de retransmisinentre2conexionestcpdondelosmensajessetransmitensincambios. Indique cual es el mtodo utilizado en la siguiente transaccin http en cliente y un servidor, indicando exactamente cuales son cada una de las partes del mensaje solicitud/respuesta,explicandoelsignificadodecadaunadelascabeceras.

El mtodo utilizado en la transaccin http es el mtodo GET. Este mtodo se utiliza para recoger cualquier tipo de informacin del servidor. Se utiliza siempre que se pulsa sobre un enlace o se teclea directamente a una URL. Como resultado, el servidor HTTP enva el documentocorrespondientealaURLseleccionada. Elmensajesecomponeprincipalmentedetrespartes: 1ElclienterealizalasolicituddeunaURI

 GET/asad/index.htmlHTTP/1.1 host:www.redes.dis.ulpgc.es Estas lneas consisten en una peticin de URI (Uniform Resource Identifier) mediante el mtodoGET.Enestaseespecificaelpathdelrecurso,laversindelprotocoloyelservidoral quesehabrconectadoanteriormenteatravsdeunaconexinTCP(puerto80). 2Elservidorrespondeconlainformacinsolicitada

3Secierralaconexin

Cuandoseintentaaccederalosejerciciosdelaasignaturaatravsdesupginaweb yhacemosclickenelenlacedeDNS(http://www.redes.dis.ulpgc.es/asad/documenta/ ejercicios/ejercicios_dns.pdf)nosaparecelasiguientecartula:

Indiquequeconjuntodeparsolicitud/respuestahttpprovocarondichasituacin. Primero el cliente realiz una peticin a la mquina www.redes.dis.ulpgc.es para obtener (mtodoGET)elfichero/asad/documenta/ejercicios/ejercicios_dns.pdfsegnlaversin1.1 delprotocoloHTTP. Seguidamente el servidor remoto respondi adems de con la versin del protocolo que utiliza,conelcdigodeestado401,queindicaqueseharealizadounaccesonoautorizado.La

inclusindelcampocabeceraWWWAuthenticateconlacuestinaresponder,enestecaso Alumnos de Redes, es obligatoria. Si la peticin previa contena ya los credenciales de acceso,entoncesestarespuestaindicaquehansidorechazadosporpartedelservidor. Miantiguoservidorweb,http://www.miantiguoweb.comestprogramadoparaque cuandoseintenteaccederal,automticamentesedireccioneasucopiaenminuevo servidor, http://www.minuevoservidor/copia_antiguo/ mediante el protocolo http. Indiquecualeselprimerdigitodelcdigoderespuestaalapeticinoriginalascomo lacabeceraderespuestaqueleindicalanuevalocalizacin. El cdigo de respuesta tendra como primer dgito un 3, lo que indica que se trata de un redireccionamientoaotraURL. La cabecera de respuesta que indica la nueva localizacin sera la cabecera Location. Esta cabecerainformasobreladireccinexactadelrecursoalquesehaaccedido.Lacabecerade respuestaqueleindicalanuevalocalizacinseraas: Location:http://www.minuevoservidor/copia_antiguo/ Indiquecualessonlascabecerasquedebenestarincluidastantoenlasolicitudcomo enlarespuestahttpcuandosedesearecargarparcialmenteunapginaweb. LassolicitudesutilizanelmtodoGETparcial,conelqueseenvaslopartedelcontenidodel recursorequerido.EstoocurrecuandolapeticintieneunacabeceraRange. La solicitud debe incluir una cabecera Range indicando el rango deseado y puede tener incluidounacabeceraIfRangeparahacerlasolicitudcondicional. Larespuestadebeincluirlossiguientescamposcabeceras: Uncampocabeceraconelrangodelcontenidoindicandoelrangoincluidoconestarespuesta. Eltipodecontenidoincluyendoelcampoderangodelcontenidoparacadaparte.Siuncampo de longitud de cabecera esta presente en la respuesta, su valor debe coincidir con el actual nmerodeoctetostransmitidosenelcuerpodelmensaje. Lafecha El ETag y/ o la localizacin del contenido, si la cabecera debia haber sido enviada a 200 respuestasalamismasolicitud. Yelcampodeexpiracin,cachecontrolyovariacinsielvalordelcampopudoserdiferente desdelaltimavezenviadaenalgunarespuestapreviaalamismavariante. Explique el siguiente intercambio de mensajes entre un cliente y un servidor http y comosesuponequeserlacontinuacindeldialogo.

 El cliente enva una solicitud mediante el mtodo GET solicitando la pgina web http://dumby.dis.ulpgc.es. Elservidorrespondeconunmensajederedireccionamiento(302=movidotemporalmente), indicando en el campo Location la ubicacin del recurso solicitado https://dumby.dis.ulpgc.es/webmail/. Lo que seguira al mensaje sera el contenido en s de la pgina solicitada (http://dumby.dis.ulpgc.es). Indiquecualeslaestructuradelosmensajesdelprotocolohttp. Enelcasodeunmensajedepeticin,lalneainicialtienelasiguenteestructura: mtodoidentificadordelrecursoversindeHTTP Trasestalneainicialesprecisoespecificarelhostalcualselesolicitaelrecursoyesposible aadirotrotipodeinformacinmedianteelusodecabeceras(paraelcasoenelquesesolicite unGETparcialocondicionalhabrqueaadirlascabecerasespecficasparaello). En el caso de un mensaje de respuesta, la lnea inicial (Status Line) tiene la siguiente estructura: versiondeHTTPcdigodeestadoderespuestafraseexplicativa Tras la lnea inicial de respuesta se puede especificar otros aspectos de la misma mediante cabeceras. Tras las cabeceras se incluir el contenido solicitado por la peticin (siempre y cuandoseaposibleaccederal).

Existealgunaformadequeunnavegadorqueutilizaelprotocolohttpversin1.1no mantenga las conexiones TCP abiertas despus de una peticin de un recurso al un servidor? Un servidor http/1.1 puede asumir que un cliente http/1.1 intenta mantener una conexin permanenteamenosqueenlacabeceradelaconexinincluyaeltrminoclosecuandose envilapeticin.Sielservidoreligecerrarlaconexininmediatamentedespusdeenviarla respuesta,estedeberaenviarunacabeceraincluyendoeltrminoclose. IndiquecualessonlosdistintosmtodosdefinidosenelprotocoloHTTP1.1. OPTIONS:peticindeinformacinsobrelasopcionesdecomunicacindisponibles. GET:requiereladevolucindeinformacinalclienteidentificadaporlaURI.SilaURIserefiere aunprocesoqueproduceinformacin,sedevuelvelainformacinynolafuentedelproceso. (existeGETcondicionalyGETparcial) HEAD:IgualqueelmtodoGET,salvoqueelservidornotienequedevolverelcontenido,slo lascabeceras.Sepuedeusarparaobtenerinformacinsobreelcontenidoquesevaadevolver enrespuestaalapeticin. POST: se usa para hacer peticiones en las que el servidor destino acepta el contenido de la peticincomounnuevosubordinadodelrecursopedido. PUT:ElmtodoPUTpermiteguardarelcontenidodelapeticinenelservidorbajolaURIdela peticin. Si esta URI ya existe, entonces el servidor considera que esta peticin proporciona una versin actualizada del recurso. Si la URI indicada no existe y es vlida para definir un nuevo recurso, el servidor puede crear el recurso con esa URI. Si se crea un nuevo recurso, deberesponderconuncdigo201(creado),sisemodificasecontestaconuncdigo200(OK) o204(sincontenido).Encasodequenosepuedacrearelrecursosedevuelveunmensajecon elcdigodeerrorapropiado. DELETE: Este mtodo se usa para que el servidor borre el recurso indicado por la URI de la peticin.No segarantiza alclientequelaoperacinselleveacaboaunquelarespuestasea satisfactoria. TRACE:seusaparasabersiexisteelreceptordelmensajeyusarlainformacinparahacerun diagnstico. CONNECT:estreservadoexplcitamenteparaelusodelosservidoresintermedioscreandoun tnelhaciaelservidordestino. HaestablecidounaconexinhttpentreelnavegadordesuPCyelservidorwebdelDIS (www.dis.ulpgc.es) y ha estado navegando, siempre dentro del mismo mediante peticionesdedistintaspginas.Sielprotocoloutilizadohasidolaversin1.1indique cuantasconexionestcpsehanestablecido. Como la versin 1.1 tiene conexiones persistentes, habremos establecido 1 conexin para navegarporlaspginaswebquesustentaelservidordelDIS.

 Indique como podria evitarse en una conexin http que las peticiones que le hace el cliente al servidor puedan ser respondidas con pginas almacenadas en un proxy cacheintermedio,esdecir,quelarespuestavengadelservidorquemantienelosdatos originales. La forma ms fcil de forzarlo es aadir las directivas{CacheControl: nocache} (para HTTP/1.1) y {Pragma", "nocache"} (por compatibilidad con HTTP/1.0} en las transacciones HTTP,locualobligaralProxyaquesenosfaciliteunacopiadelapaginawebensuestado actual,ynoenelestadoenelqueseencuentraenlacach. UnclientehaemitidounasolicitudaunservidorutilizandoelmtodoPUTobteniendo unarespuestaafirmativaconcdigo201created.Indiquequecabeceraderespuesta concretadebeestaralmenosincluidaenelconjuntodecabecerasderespuesta. MedianteestarespuestaseindicaalclientequeelrecursoindicadoconelmtodoPUThasido creado. La respuesta incluye una cabecera Location: con el URI del recurso creado, es decir, el URI usado para editar la entrada, como opuesto al URI empleado para mostrar el contenido.Elcuerpodelarespuestacontendrlaentrada"rellenada"conlas estampaciones de tiempo y cualquier otro dato que el servidor elija revelar. Debe contener suficiente informacin para habilitar al cliente para poder proceder a un subsiguiente PUT a estalocalizacin.