Copyright (C) 1995 by Julião Braga & Oscar Farias 1 World Wide Web.

Copyright (C) 1995 by Julião Braga & Oscar Farias 1

World Wide Web

rerererreytghgfhggfhgfhgfhnnbvnbnb


ffdf999

rerererreytghgfhggfhgfhgfhnnbvnbnbjjlkdjjdjjjdsdadadddsdasd

rerererreytghgfhggfhgfhgfhnnbvnbnbhfhgfhjjghjhgjhgkjlkjlllllll


ffdf999

rerererreytghgfhggfhgfhgfhnnbvnbnblljkljklkhjkhjkkk

ooiopiopoppooopioioppoiipoiopiuiouuiouiiuiouuuiuinmm,mnm





World Wide Web

host 1 - br

host 2 - ca

host 4 - fr

host 5 - us

host 3 - br


World Wide Web

• Propiciar aos usuários, a partir de uma forma unificada, acesso a

documentos “hypermedia” situados em qualquer computador

conectado à Internet.

• Os usuários navegam pelo universo dos documentos da WEB guiados pelos “hyperlinks”, através de simples “point and click” do mouse.


Idéias Básicas na Concepção da World Wide Web

• Trata-se de um (super) sistema de informação distribuído por computadores existentes em todo o mundo.

• A Web é uma coleção de protocolos e padrões para acesso à informação na Internet.

• Suporte a “Hypermedia” - Pode-se visualizar textos, figuras, sons e animações recuperadas de computadores localizados em qualquer local do planeta.

• Extensibilidade: de modo que todo e qualquer formato de dados seja suportado


Terminologia

• Um objeto na WEB é um conjunto de dados na forma de um arquivo. O arquivo pode conter qualquer tipo de dados: textos, imagens gráficas, vídeo, áudio, ou quaisquer combinações destes tipos de dados.

• Documento objeto (“document object”): documento (página) na WEB que pode conter qualquer tipo de dados.

• “WEB site”: é um conjunto de páginas interligadas e conceitualmente relacionadas, usualmente residindo em uma mesma máquina.

• “Browser”: é um programa que sabe como navegar na WEB, como se comunicar com os servidores e recuperar dados, apresentando-os aos usuários.

• Servidor: é um “software” que gerencia a informação de um “WEB site”. O servidor atende às solicitações (“requests”) dos “browsers” (clientes).

Cliente

Cliente

Cliente

Servidor


Arquitetura Cliente-Servidor: a Base da WEB

• O cliente e o servidor são programas que se comunicam entre si.

• O cliente contacta o servidor e solicita uma dada informação.

• O servidor atende ao pedido (“request”) do cliente.

• Os “browsers” (ex.: Netscape e Mosaic) são os clientes que contatam os servidores WEB (ex.: CERN e NCSA, Netscape). Efetuam um pedido e depois mostram (“renderizam”) a informação para o usuário.

• O trabalho do servidor é esperar pelas conexões externas dos clientes, “ouvir” os seus pedidos e atendê-los, quando possível.

• Para que os servidores e clientes possam se comunicar eles devem observar um protocolo, que estabelece as regras a serem observadas na comunicação


Protocolos e Padrões WEB

• A WEB não posui um padrão ou protocolo único. Engloba vários padrões e protocolos, de sorte que os usuários podem ter acesso a informações usando qualquer um desses protocolos e/ou padrões.

• A WEB é basicamente definida por 4 padrões/protocolos:

– HTTP - Hypertext Transfer Protocol– URLs - Uniform Resource Locators– HTML - Hypertext Markup Language– CGI - Common Gateway Interface

• Os servidores e clientes da WEB usam estes padrões como mecanismos simples para localizar, ter acesso e mostrar a informação desejada.


HTTP - Hypertext Transfer Protocol

• É o principal protocolo para a distribuição de informação na WEB.

• Para entregar a informação solicitada ao cliente, o HTTP define uma transação simples constando de 4 partes:

1) O cliente estabelece uma conexão com o servidor.

2) O cliente submete um pedido ao servidor especificando que deseja recuperar um determinado documento.

3) O servidor envia uma resposta contendo um código de “status” e a representação eletrônica do documento, se disponível.

4) Ou o cliente ou o servidor desconectam.

O Intercâmbio da Informação Cliente-Servidor

Cliente Servidor

O cliente se conecta

O cliente solicita

O servidor responde

Fecha-se a conexão


• Modelo Cliente-Servidor: objetivando a transferência de dados “hypermedia”.

• Simplicidade: quando o cliente conecta-se com o servidor, a única informação que o cliente deve enviar é o “request method” e a URL (Universal Resource Locator) - o endereço do recurso na Internet.

• Flexibilidade e “Content-Typing”: o HTTP possibilita a transmissão de dados de tipos arbitrários. “Content-Typing” identifica o tipo de dado sendo transmitido.

• “Connectionless”: o HTTP é um protocolo “connectionless”, o que significa que há um limite de um “request” por conexão.

Há maior eficiência, pois o servidor não gasta tempo quando não há pedidos a atender e nem gasta recursos para guardar o estado da conexão.

Atributos Chaves do Protocolo HTTP (i)


Atributos Chaves do Protocolo HTTP (ii)

• “Stateless”: o servidor não se lembra de nada referente às solicitações anteriores. Há uma conexão para cada pedido.

Vantagem: rapidez, pois o servidor não precisa manter informações sobre o estado do protocolo.

Desvantagem: Transmitir mais informações a cada conexão, pois as informações necessárias da transação anterior têm que ser retransmitidas.

• Meta-informação: possibilita ao servidor prover informação sobre o dado que está sendo enviado.

Meta-informação é a informação que nos diz como interpretar os dados. Exemplo: i) o campo “referer”, para identificar o documento que contém o “link” que nos levou ao documento atual; ii) o tamanho do corpo do documento. Pode ser usada para fazer “requests” condicionais e reportar o sucesso de uma transação


Categorias de Meta-informação suportadas pelo HTTP

• General message header: provê informação não diretamente relacionada ao pedido, resposta, ou objeto sendo transmitido. É usado tanto no pedido (request) como na resposta (response).

• Request header: qualifica a solicitação (request) em andamento, dizendo ao servidor como interpretá-la.

• Response header: contém informações relacionadas à resposta do servidor

• Entity header: estes campos provêm informação sobre o objeto que está sendo retornado. Esta A informação explica como interpretar o objeto sendo submetido.


Campos do General Message Header

• Date: data e momento no qual a mensagem se originou.

• Forwarded: usado pelos servidores “proxy” para indicar o caminho percorrido do cliente ao servidor. Usado para diagnósticos em problemas de transmissão.

• Message-id: contém um número de identificação para cada mensagem.

• Mime-version: especifica a versão do MIME utilizada na mensagem sendo enviada. Default: MIME v. 1.0


Campos do Entity Header (i)

• Allow: lista os métodos HTTP padrões que são válidos para uso com o objeto que está sendo transmitido.

• Content-Length:especifica o tamanho do Entity-Body em bytes. Sem este campo o cliente não saberia quanto deveria ler e nem quando parar.

• Content-Type: refere-se ao “MIME Internet Type” para o objeto retornado. Pela identificação do tipo do objeto retornado, o cliente pode agir de modo apropriado.

• Content-Encoding: especifica os mecanismos de compressão, criptografia e empacotamento usados para codificar o objeto

• Content-Transfer-Encoding: É usado para especificar qualquer mecanismo de codificação usado para transferir dados para o cliente. Valores aceitáveis incluem: 7bit, 8 bit, binary, quoted-printable, e base64.

• Content-Language: identifica a línguagem natural do objeto.


Campos do Entity Header (ii)

• Expires: data na qual o dado torna-se não válido.

• Last-Modified: data e o tempo em que o objeto especificado foi modificado pela última vez.

• URI: usado para retornar a nova URI para o objeto se o objeto foi movido. Substituiu o campo location.

• Location: usado para retornar um URI para o objeto que se moveu.

• Version: número da versão do documento sendo retornado.

• Derived From: contém o número da versão do documento anteriormente a qualquer modoficação feita pelo “request”.

• Title: título do objeto.

• Link: especifica uma ou mais relações de link entre o objeto sendo enviado e outros objetos.


Multipurpose Internet Mail Extension - MIME (i)

• MIME - definido nos RFCs (“Requests For Comments” 1521 e 1522)

• É um padrão projetado para suportar a inclusão de objetos com múltiplos tipos em um único objeto.

• Originalmente concebido para e-mail, para possibilitar, p. ex., a anexação de uma figura (ou som ) a uma mensagem.

• Para tanto o MIME definiu o campo “Content-Type-Header” baseado no padrão previamente definido no RFC 1049.

• A especificação estabelece que este campo venha antes do real conteúdo da mensagem de e-mail, e deve descrever suficientemente o dado contido no corpo da mensagem, de modo que o agente usuário receptor possa selecionar o mecanismo ou agente apropriado para apresentar o dado ao usuário, ou, então, lidar com o dado de forma apropriada.


A Sintaxe do MIME Content-Type

• type/subtype; parameter; parameter; ... parameter;

onde: subtype especifica um tipo de formato particular para o tipo de dado.

• Exemplos:

– text/html– video/mpeg– image/gif– audio/basic


A Comunicação Cliente-Servidor: Abrindo uma Conexão

• Quando um servidor HTTP está executando, ele está ouvindo uma porta (geralmente a porta 80) e esperando pela ocorrência de uma conexão.

• Tecnicamente falando, o cliente abre um “socket” e associa este “socket” com a porta.

• Como em UNIX tudo é arquivo, um “socket” é um tipo especial de arquivo que possibilita I/O para a rede.

• Quando se abre um “socket”, do ponto de vista do cliente está se criando um arquivo virtual.

• Quando se escreve neste arquivo, na realidade está se enviando dados para a rede


A Comunicação Cliente-Servidor: Fazendo um Pedido (“Request”)

• Um “request” HTTP 1.0 é um “string” de caracteres com uma ou mais linhas, seguidas por dois “carriage-return line-feeds” (CRLFs).

• A primeira linha é a linha do pedido. Ela inclui:

um método, a URI e o protocolo

• O restante das linhas são “headers” de vários tipos:

general headers, request headers e finalmente os entity headers.

• Os dois CRLFs sinalizam o fim do pedido”.


• Method URI HTTP-Version

General-Header

Request-Header campos opcionais

Entity-Header (meta-informação)

---- linha em branco -----

Entity-Body ----- comprimento determinado pelo

Entity-Header

2 CRLFs

• Exemplo:

GET /products/tvset.html HTTP/1.0

Formato de um Pedido Completo


Métodos (i)

Um método descreve a ação que deve ser realizada no recurso especificado.

• GET: é usado para solicita a um servidor o objeto especificado pela URI.

• documento ou arquivo

• programa ou script

• consulta a base de dados

• HEAD: é usado para perguntar ao servidor sobre a meta-informação associada ao objeto (às vezes só se quer saber o tamanho do objeto e a data de sua última modificação).

Muito útil para testar a validade e acesso aos links.


Métodos (ii)

• POST: é usado quando se precisa transferir dados do cliente para o servidor, a fim de que o servidor possa então, tratá-los.

O método POST é usado com freqüencia para submeter o conteúdo de um formulário HTML a um servidor HTTP, que se encarregará de processá-lo.

• PUT: é usado quando se cria um novo recurso ou se atualiza um recurso já existente.

O método PUT submete dados ao servidor, para que fiquem disponíveis via uma URI especificada. Se os dados já existem na URI, eles são usados como uma nova versão. Se os dados não existem , o servidor tenta criar um novo recurso (com os dados) na URI especificada.


Métodos (iii)

• DELETE: diz ao servidor para remover o recurso especificado.

• LINK: é usado para dizer ao servidor para adicionar relações de links ao objeto especificado na URI.

As relações de link podem indicar que um recurso é a continuação de um outro recurso, o predecessor, o pai, etc...

• UNLINK: remove relações de link do objeto especificado pela URI.


Campos do “Request-Headers” (i)

• User-Agent: identifica o programa cliente. Em geral é o nome do “browser’.

Sintaxe: User-agent: product_list

onde, product_list é uma lista de strings na forma product_name ou product_name/product_version.

É usado para fins estatísticos.

O servidor pode usar este campo para para modoficar a resposta retornada ao cliente.

• If-Modified-Since: usado, em conjunção com o método GET, para produzir um pedido condicional.

O servidor sómente retorna o objeto se ele foi modificado após a data determinada. Se o objeto não foi modificado após a data, o servidor retorna o código de “status” 304.


Campos do “Request-Headers” (ii)

• Pragma: solicita ao servidor um comportamento determinado. A única opção no HTTP/1.0 é “no-cache”. Este valor especifica aos “caching servers” que recebem o pedido, de que devem realmente pedir o documento, independentemente do mesmo estar “cached”.

• Authorization: contém a informação de autenticação que é para ser enviada junto com a solicitação. O servidor pode recusar a solicitação se o cliente não possui as permissões apropriadas.

• Referer: identifica o objeto contendo o link que originou o pedido corrente.

.

• From: endereço de e-mail do usuário que está fazendo o pedido


Campos do “Request-Headers” (iii)

• Accept: especifica um conjunto ou lista de “Content-Types” que o cliente aceitará como resposta

• Accept-Charset: especifica o conjunto de caracteres que o cliente pode aceitar.

• Accept-Encoding: especifica uma lista ou conjunto de tipos de codificação de conteúdo (“content-encoding-types”) que o cliente aceitará como resposta

• Accept-Language: lista de linguagens naturais que o cliente aceitará como resposta.


A Comunicação Cliente-Servidor: A Resposta

• Uma resposta de um servidor HTTP/1.0 é um string de uma ou mais linhas, seguidas por uma linha em branco e pelo Corpo da Entidade (“Entity-Body”).

• A primeira linha é a linha de resposta. Ela inclui o protocolo do servidor e o código de “status”.

• As linhas restantes são “headers” de um ou outro tipo. Primeiro os “General Headers”, depois os “Response Headers” e, finalmente, os “Entity Headers”.

• Segue-se uma linha em branco separando os headers do objeto.


Forma Completa da Resposta

• HTTP-Version Status-Code Reason-Phrase

General-Header

Response-Header campos opcionais

Entity-Header (meta-informação)

----- linha em branco ---

Entity-Body ----- tem o seu comprimento

determinado pelo Entity-Header

• a linha em branco serve como um delimitador entre os “headers” e o “Entity-Body”.• Os campos “General-Headers” usados nas respostas são os mesmos utilizados nos

pedidos.


Exemplo de Pedido e Resposta Associada

HEAD / HTTP/1.0 --- pedido

HTTP/1.0 200 OK --- resposta

Date: Monday, 09-Oct-95 22:27:14 GMT

Server: NCSA/1.3

MIME-version: 1.0

Content-type: text/html

Last-modified: Friday, 29-Sep-95 16:23:46 GMT

Content-length: 1774

.


Códigos de “Status”

• Código de “Status”: Indicam se o servidor foi capaz de atender à solicitação com sucesso

• Categorias dos códigos:

– 1: reservada para uso futuro– 2: indica sucesso– 3- indica a ocorrência de redireção– 4: indica erro do cliente– 5: indica erro do servidor


Campos do “Response Header”

• Server: identifica o software servidor.

Sintaxe: User-agent: product_list

onde, product_list é uma lista de strings na forma product_name ou product_name/product_version.

• WWW-Authenticate: informa ao cliente que a URI solicitada é protegida e é necessária autenticação. Também informa o esquema que está sendo usdo para realizar a autenticação.

• Retry-After: especifica o espaço de tempo que deve transcorrer, até que o recurso esteja novamente disponível.

• Public: Possibilita ao servidor especificar uma lista de todos os métodos não-padrões suportados pelo servidor.


A Comunicação Cliente-Servidor: O Término da Conexão

Quando ou o cliente ou o servidor desfazem a conexão, o pedido é terminado, independentemente da transação ter sido completada ou bem sucedida.


Evolução do HTTP

• A realização de negócios via Internet (vendas on-line) depende, basicamente, na segurança das operações comerciais realizadas.

Há, portanto, uma forte demanda para mecanismos de autenticação e criptografia.

• Propostas existentes

– S-HTTP (Secure HTTP)– Shen– Secure Sockets Layer (SSL)– Uma nova versão do HTTP está sendo definida, chamada

HTTP-NG


Uniform Resource Locators - URLs (i)

• Universal Resource Identifier (URI): esquema de identificação para os recursos da Internet que engloba os URLs e URNs.

• Uniform Resource Name (URN): esquema para nomear recursos na Internet e que pode ser usado para mapear um nome particular em um ou mais recursos.

• Uniform (Universal) Resource Locator (URL): uma forma para identificar a localização exata de um recurso na Internet.

• Referências:

– RFC 1738 - URLs

– RFC 1630 - URIs

– RFC 1737 - URNs


Uniform Resource Locators - URLs (ii)

• Para descrever um objeto, um nome deve possuir as seguintes características:

– Persistência: um dado nome deve permanecer válido por tanto tempo quanto necessário.

– Extensibilidade: a sintaxe de um dado nome deve permanecer válida, em que pese a introdução de novos protocolos .

– Resolvível: um nome deve possuir informação suficiente para possibilitar o acesso ao documento ou índice a que se refere.

– Unicidade: Cada objeto deve possuir um nome único.

– Não-ambígüo: Se dois nomes são idênticos, então referem-se ao mesmo objeto.


Uniform Resource Locators - URLs (iii)

• Identificar um recurso na Internet requer, não apenas a especificação de sua localização física, mas também o protocolo que deve ser usado para recuperar os dados.

• O formato de todas as URLs dependem do protocolo usado para se ter acesso ao recurso. Todavia, vários protocolos compartilham um formato comum de URL conhecido como:

Common Internet Scheme Sintax (CISS)

• Formato geral do CISS:

schemename://username:password@host:port/path


Uniform Resource Locators - URLs (iv)

• scheme: é o formato, na URL, para um protocolo particular. Em geral os esquemas correspondem aos protocolos usados para se ter acesso aos dados.

– FTP, HTTP, Gopher, WAIS, Prospero e acesso a arquivos aderem ao CISS.

– Mailto e News não aderem ao CISS.

• path: identifica o recurso.

• URLs que seguem o formato CISS são um subconjunto do formato geral para todas as URLs. O formato geral consiste de:

scheme:scheme-specific-string


Formato das URLs

Esquema------------FTP

HTTPGopherMailtoNewsNNTP

Telnet

WAISFileProspero

Formato da URL-------------------------------------------ftp://user:password@host:port/path

http://host:port/path?searchpartgopher://host:port/pathmailto:local-address@hostnews:newsgroup-namenntp://host/newsgroup-name/ article-numbertelnet://user:password@host:port

wais://host:port/databasefile://host/pathprospero://host:port/hsoname;field= value

Defaults--------------------------------------Username = anonymousPassword = endereço de e-mail do usuárioPorta = 21Porta = 80Porta = 70nenhumnenhumPorta = 119

Porta = 23Se omitida, é solicitado aousuário o username e passwordPorta = 210nenhum

Usual------------------------ftp://host/path

http://host/pathgopher://host/path

telnet://host:port


Exemplos de URLs (i)

• ftp://ftp.pegasus.br/pub/sumario

• http://www.pegasus.com/

Atenção! A barra (/) é o nome de um recurso como qualquer outro nome. A maioria dos “sites” usa a barra (/) como o seu recurso de nível mais elevado, ou “home page”.

• http://www.pegasus.com/cgi/wandex?word=computers

Neste caso, path=/cgi/wandex e searchpart=word=computers.

Esta URL faz uma conexão HTTP com www.pegasus.com na porta 80. Ela solicita ao script CGI Wandex que elabore uma lista dos “sites” relacionados a computadores. Normalmente o texto a ser pesquisado é o resultado da submissão de um formulário a ser preenchido com a palavra a ser pesquisada.


Exemplos de URLs (ii)

String--------%09%0a%20%40%26%3f

Exemplo--------------------------------Coluna1%09Coluna2Line1%aLine2Oscar%20FariasJuliao%40.pegasus.comgatos%26sapatosHow%20are%20you%3f

Significado do Valor Codificado-------------------------------------Tabcaracter “new-line”espaçosímbolo at (@)& comercial (“ampersand”)ponto de interrogação (?)

• gopher://qwis.circ.gwu.edu:70/11/General%20Information/

Train%20Schedules/Amtrak%20Train%20Schedules

Neste caso, o path é: /11/General Information/Train Schedules

o recurso: Amtrak Train Schedules

Atenção! A inclusão de caracteres especiais em uma URL pode ser feita substituindo-os pela seqüência de escape correspondente.


Exemplos de URLs (iii)

• mailto:[email protected]

• news:comp.infosystems.www.misc.

• nntp://news.rdc.puc-rio.br/comp.parallel Atenção: A maioria dos servidores NNTP (servidores de NEWS) são

configurados para aceitar conexões apenas de uma lista de clientes conhecidos

• telnet://callsign.cs.buffalo.edu:2000

Atenção: Os outros protocolos identificam recursos. Já o propósito de uma URL telnet é identificar um recurso interativo de uma máquina remota.

• wais://host:port/database

WAIS - Wide Area Information System. Para pesquisar material indexado em uma base de dados.


Exemplos de URLs (iv)

• wais://host:port/database?search Search é o critério para a pesquisa na base de dados.

• wais:// host:port/database/wtype/wpath

Wtype é o tipo do objeto;

Wpath é o identificador do documento objeto no índice WAIS

• Prospero: ainda não existem clientes WEB que implementem este esquema diretamente. Todavia o Archie é um cliente Prospero que permite a pesquisa em bancos de dados de objetos Prospero.

No formato geral:

prospero://host:port/hsoname;field=value Hsoname é o nome do objeto Prospero a ser recuperado;

Field e value ajudam a identificar o objeto.


URLs Relativas

• Especificam a localização de um recurso relativamente ao documento em que são referenciadas.

• URLs relativas ao servidor: especificam o caminho completo do recurso, mas não o protocolo, nome do servidor ou porta.

é possível alterar o nome do servidor ou a porta em que ele está escutando sem ter que alterar o texto de quaisquer documentos.

• URLs relativas ao documento: somente especificam um caminho relativo ao documento em que estão.

pode-se mover subsessões do seu “site” para outra máquina ou outra localização dentro do “site” (p. ex.: outro diretório)

Caracter-----------

String exemplo-----------------------------------

Significado--------------------------------------------------------------

// http://pegasus.com quando este string segue-se ao esquema, indica que a URLadere ao CISS

: www.intermail.com:80 Usado para separar o nome do “host” do número da porta

/ i) www.lncc.br:80/entr.htmlii) entr.html/tutoriais.html

Separa o nome do “host” e a porta do “path”É também comumente usado no “path” da URL paradesignar uma hirarquia ou estrutura de diretórios

? /cgi/wais.pl?palavra-chave Dentro do “path” de uma URL HTTP, a “?” denota oinício de um “query string”; o texto que se segue não éinterpretado como o nome do arquivo, mas como dadossubmetidos pelo usuário

+ wais.pl?gatos+cachorros Dentro de um “query string” de uma URL HTTP significaum AND Booleano das palavras

= /cgi/wandex?keyword=mime Dentro de um “query string” de uma URL HTTP servecomo delimitador entre a chave (“key”) e o valor (“value”)para um campo

& /cgi/register?name=Oscar&companhia=Pegasus

Dentro de um “query string” de uma URL HTTP o “&”comercial delimita conjuntos de pares chave-valor

~ http://www.pegasus.com/~juliao Ao início de um “path”, um “~” indica que o recursoespecificado está no diretório “home” do usuário


HTTP: A Troca de Informações Cliente-Servidor (i)

[pegasus:~] telnet www.lncc.br 80

Trying...

Connected to fs2.sp1.lncc.br.

Escape character is '^]'.

HEAD / HTTP/1.0

HTTP/1.0 200 OK


Server: NCSA/1.3

MIME-version: 1.0


Last-modified: Friday, 29-Sep-95 16:23:46 GMT

Content-length: 1774

Connection close


[pegasus:~] telnet www.lncc.br 80

Trying...

Connected to fs2.sp1.lncc.br.


GET / HTTP/1.0

HTTP/1.0 302 Found


Server: NCSA/1.3

MIME-version: 1.0

Location: http://fs2.sp1.lncc.br:80/


<HEAD><TITLE>Document moved</TITLE></HEAD>

<BODY><H1>Document moved</H1>

This document has moved <A HREF="http://fs2.sp1.lncc.br:80/">here</A>.<P>

</BODY>

Connection closed.

HTTP: A Troca de Informações Cliente-Servidor (ii)

HTTP: A Troca de Informações Cliente-Servidor (iii-a)

[pegasus:~] telnet www.ibm.com 80

Trying...

Connected to www.ibm.com.


GET / HTTP/1.0

HTTP/1.0 200 Document follows

Date: Sat, 14 Oct 1995 16:40:16 GMT

Server: NCSA/1.4.2


<!doctype html public "-//IETF//DTD HTML 2.0//EN">

<HTML>

<HEAD>

<TITLE>The IBM world wide web home page</TITLE>

<META NAME="KEYWORDS" CONTENT="homepage home page index ibm international business machines">

<META NAME="OWNER" CONTENT="[email protected]">

<META NAME="ABSTRACT" CONTENT="The IBM Corporate Home Page">

<META NAME="CC" CONTENT="int">

<META NAME="LANGUAGE" CONTENT="en.us">



</HEAD>


HTTP: A Troca de Informações Cliente-Servidor (iii-b)

<BODY>

<H1><IMG WIDTH=480 HEIGHT=100 ALT="IBM October" SRC="/images/mastheads/homepage.

gif"></H1>

<BR>

<A HREF="/Newsfeed/" TITLE="Newsfeed"><IMG SRC="/images/icons/newsfeed.gif" BORDER=0 ALT="Newsfeed"

WIDTH=75 HEIGHT=88></A>

<A HREF="/Stretch/" TITLE="Stretch"><IMG SRC="/images/icons/stretch.gif" BORDER=0 ALT="Stretch"


<A HREF="/Products/" TITLE="What we offer"><IMG SRC="/images/icons/products.gif" BORDER=0 ALT="What we offer"


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

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

<a href="http://www.ibm.com/copyright.html">(C)</a> |

<a href="http://www.ibm.com/trademarks.html">(TM)</a>

]

</b>

</body>

</html>

Connection closed.

[pegasus:~]


Hypertext Markup Language - HTML (i)

• HTML é o mecanismo usado para apresentar os documentos (páginas) na WEB e definir as características relativas à sua aparência.

• Princípios:

– Linguagem comum usada para agregar (alinhavar) informações de diferentes fontes

– Simples, tanto para os autores de documentos HTML como para programadores

– Acomodar as mudanças tecnológicas e sociais no uso da WEB

– Prover visualização independente da plataforma usada


Hypertext Markup Language - HTML (ii)

• “Markup Languages”: são usadas para descrever o “lay-out” (apresentação) dos documentos.

• “Tags” ou marcas especiais são inseridas dentro do texto original, indicando como o mesmo deverá ser apresentado.

• O HTML é definido em termos da “Standard Generalized Markup Language”, um padrão ISO utilizado para definir linguagens de “markup”.


“Standard Generalized Markup Language” (i)

• Níveis de informação existentes em qualquer comunicação:

– conteúdo

ex.: frase, discurso ...– sobre o conteúdo (“markup”)

ex.: sorriso, postura irônica, etc...• A SGML não é um conjunto de códigos padrões:

ex.: indicativos de fonte maior, negrito, novo parágrafo, etc.

i) O número de códigos necessários teóricamente estaria em aberto (existem muitos tipos de documentos com diversos elementos de “markup”);

ii) não haveria como tratar os eventuais erros


“Standard Generalized Markup Language” (ii)

• SGML é uma meta-linguagem, isto é, um meio de descrever formalmente uma linguagem, no caso as linguagens de markup

• SGML é uma linguagem usada para criar a definição de um tipo de documento (“document type definition”- DTD) que define precisamente os elementos e outras construções necessárias para um documento ou para um grupo de documentos estruturados de forma semelhante.

• A definição dos elementos (declaração dos elementos) tem duas funções críticas:

– indicar o nome oficial do elemento, que aparecerá entre delimitadores como uma “tag”(ex.: <capítulo>);

– descrever o que cada elemento pode conter (“content model”).


“Standard Generalized Markup Language” - Exemplo

• Sintaxe, em SGML, para definir o capítulo de um livro simples e sem figuras:

<ELEMENT capítulo (capítulo, (parágrafo | cabeçalho)+ )

<ELEMENT (capítulo | parágrafo | cabeçalho) (#PCDATA)

símbolo significado

+ uma ou mais vezes

| ou

, seguido de

(...) indica grupamento

PCDATA indica que os elementos assim definidos não possuem sub-elementos; eles contêm apenas os caracteres que constituem o conteúdo do documento (“parsed character data”)


“Standard Generalized Markup Language” (iii)

• O HTML é definido de forma semelhante!

• Todo documento HTML possui três partes:

– i) Uma declaração SGML que associa quantidades de processamento e nomes de “tokens” de sintaxe a valores específicos. Esta declaração informa ao sistema receptor exatamente qual o conjunto de caracteres, delimitadores e “features” opcionais SGML estão sendo usadas.

Ex.: a declaração SGML no HTML DTD especifica que o “string” que abre uma “tag” é </ e o comprimento máximo de um nome é 40 caracteres.


“Standard Generalized Markup Language” (iv)

– ii) Um prólogo, incluindo uma ou mais declarações de tipos de documentos, relações de elementos e atributos, e referências que podem ser representadas por “markup”. Esta parte, conhecida como Document Type Definition, diz exatamente a um sistema que markups deve esperar.

Ex.: A HTML DTD especifica que o elemento HEAD contém, no máximo, um elemento TITLE.

– iii) Uma instância, que contém os dados e os “markup” do documento.

Ex.: o “source” de uma “home page” particular escrito em HTML.


Hypertext Markup Language - HTML (iii)

• Importante: Todos os documentos HTML compartilham a mesma declaração SGML e o mesmo prólogo. Assim, nas implementações WEB em geral somente se transmite e armazena a parte correspondente à instância do documento HTML.

• HTML 1.0 padrão

• HTML 2.0 “internal draft”

• HTML 3.0 “internal draft”


Hypertext Markup Language - HTML (iv)

• Um elemento em HTML é um identificador para certas partes de um objeto, incluindo como a parte do objeto é “renderizada” (apresentada), como o objeto é “linkado” (associado) a diferentes objetos, etc...

• Os elementos HTML possuem tres partes:– “tag” inicial: indica o início do elemento;entre os delimitadores (<) e (>)

tem-se o nome do elemento seguido pelos atributos correspondentes.

– O conteúdo: tudo o que aparece entre as “tags” inicial e final de um elemento é definido pelo elemento (“marked up”). O conteúdo de um elemento pode ser constituído por texto e outros elementos HTML.

– “tag” final: sinaliza o término do elemento. Seus delimitadores são (</) e (>).

Copyright (C) 1995 by Julião Braga & Oscar Farias 1 World Wide Web.

Documents

Transcript of Copyright (C) 1995 by Julião Braga & Oscar Farias 1 World Wide Web.