Segundo a rfc 2109

Um cookie pode ter no maximo 4k, um navegador pode ter no maximo 300 cookies e cada dominio no maximo 30 cookies.

Abaixo o documento na integra:

Netscape Communications
Fevereiro 1997
HTTP Estado mecanismo de gestão

Status do presente Memo

Este documento especifica um protocolo Internet normas para a pista
Comunidade Internet, e solicita discussão e sugestões para
melhorias. Por favor, referir-se a actual edição do “Internet
Jornal Protocolo Standards “(1 DST) para o estado de normalização
e do estatuto do presente protocolo. A distribuição deste memorando é ilimitado.

1. RESUMO

Este documento especifica uma maneira de criar uma sessão com stateful HTTP
solicitações e respostas. Ela descreve dois novos cabeçalhos, e Cookie
Set-Cookie, que carregam informações entre os participantes estatais
servidores de origem e os agentes do utilizador. O método descrito aqui difere
a partir da Netscape Cookie proposta, mas pode interoperar com
HTTP/1.0 usuários que utilizam agentes da Netscape método. (Veja o histórico
seção.)

2. TERMINOLOGIA

Os termos utilizador agente, cliente, servidor proxy, e têm origem servidor
o mesmo significado que na especificação HTTP/1.0.

- Nome de host totalmente qualificado (FQHN) significa que o pleno-qualificados
domain name (FQDN) de um anfitrião (ou seja, um total domínio especificados
nome que termina em um domínio de topo como o. com ou. Reino Unido), ou o
numéricos IP (Internet Protocol) endereço de um host. O plenamente
qualificada nome do domínio é preferida; uso do endereço IP numérico é
fortemente desencorajado.

As condições de acolhimento e de solicitação de pedido-URI referem-se aos valores do cliente
seria enviado para o servidor como, respectivamente, o hospedeiro (mas não do porto)
abs_path e porções do absoluteURI (http_URL) do HTTP
solicitação linha. Note que o pedido de acolhimento tem de ser um FQHN.
Kristol Standards Track & Montulli [Page 1]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
Hosts nomes pode ser especificado quer como um endereço IP ou um FQHN
string. Às vezes temos uma comparação com outro nome de host. A anfitriã da
nome de domínio jogos acolhimento B do caso

* Ambos são nomes de host e os seus endereços IP nome do host cordas jogo
exactamente; ou

* Ambos são nomes de host FQDN cordas e as suas cordas correspondem nome de host
exactamente; ou

* Um FQDN é uma string e tem a forma NB, onde N é um nome não-vazio
string, B tem a forma. B ‘, e B’ é um FQDN string. (Então, x.y.com
domain-jogos. y.com mas não y.com.)

Note que o domínio de jogo não é uma operação comutativa: abccom
domain-jogos. c.com, mas não o inverso.

Porque foi usado no Netscape inicial da execução do estado
gestão, vamos usar o termo “cookie” para se referir ao estado
informação que passa entre uma origem servidor e usuário agente, e
que será armazenado pelo agente do utilizador.

3. Estado e sessões

Este documento descreve uma forma de criar stateful com sessões HTTP
solicitações e respostas. Atualmente, HTTP responder a cada
pedido, sem que o cliente relativas ao pedido anterior ou
subsequentes pedidos, a técnica permite que clientes e servidores
Desejo para a troca de informações ao estado local e solicitações HTTP
respostas dentro de um contexto maior, que nos termos de uma “sessão”. Este
contexto poderia ser usado para criar, por exemplo, um “carrinho”, em
utilizador seleções que podem ser agregados antes da compra, ou uma
Revista navegando sistema, em que um usuário da leitura anterior afecta
ofertas que são apresentados.

Existem, naturalmente, muitos contextos diferentes potenciais e, portanto, muitas
diferentes tipos potenciais de sessão. Os designers “paradigma
sessões criadas pela troca de cookies tem esses atributos chave:

1. Cada sessão tem um início e um fim.

2. Cada sessão é relativamente curta.

3. Ou o usuário agente ou de origem pode encerrar um servidor
sessão.

4. A sessão está implícito na troca de informações de estado.
Kristol Standards Track & Montulli [Página 2]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
4. ESQUEMA

Temos aqui um esboço caminho para uma origem estatal servidor para enviar informações
agente para o usuário, e para o usuário agente de voltar ao estado
a informação do servidor origem. O objetivo é ter um mínimo
impacto sobre o HTTP e os agentes do utilizador. Somente servidores que precisam de origem
manter sessões iria sofrer qualquer impacto significativo, e que
impacto pode ser largamente comum limita a Gateway Interface (CGI)
programas, a menos que o servidor fornece mais sofisticados estado
apoio à gestão. (Veja Implementação considerações, abaixo.)

4,1 Sintaxe: Geral

Os dois cabeçalhos de gestão estatal, e Set-Cookie Cookie, têm comum
sintática propriedades envolvendo pares valor-atributo. A seguir
gramática utiliza a notação, e fichas DIGIT (dígitos decimais) e
token (informalmente, uma seqüência de não-especial, não-brancos espaço
caracteres) a partir da especificação HTTP/1.1 [RFC 2068] para descrever
sua sintaxe.

- av = av pares de par-par *(”;” av)
AV-pair = attr [ "=" valor]; valor opcional
attr = token
= valor palavra
palavra = token | citou-corda

Atributos (nomes) (attr) são caso-insensitivo. White espaço é
permitidas entre fichas. Note que, embora a sintaxe acima
descrição mostra valor como opcional, attrs exigir mais deles.

NOTA: A sintaxe acima permite que entre o branco eo atributo
o sinal =.

4,2 origem servidor papel

4.2.1 Geral

A origem servidor inicia uma sessão, se assim o desejar. (Note que
“sessão” aqui não se refere a uma conexão de rede, mas persistente
para uma sessão lógico criado a partir de solicitações HTTP e respostas. O
presença ou ausência de uma conexão persistente não deverá ter qualquer efeito
sobre o uso de cookies-derivados sessões). Para iniciar uma sessão, o
origem servidor retorna uma resposta cabeçalho extra para o cliente, Set -
Cookie. (Os detalhes seguem mais tarde.)

Um usuário agente retorna um pedido cabeçalho Cookie (veja abaixo) para o
origem servidor se ele optar por continuar a sessão. A origem servidor
maio ignorá-lo ou utilizá-la para determinar o estado actual da

Kristol Standards Track & Montulli [Página 3]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
sessão. Ela pode enviar de volta para o cliente uma resposta cabeçalho Set-Cookie
com o mesmo ou diferente informação, que pode ou não enviar nenhum Set-Cookie
cabeçalho de todo. A origem servidor efetivamente termina com uma sessão
enviar ao cliente um cabeçalho Set-Cookie com Max-Age = 0.

Servidores pode retornar uma resposta cabeçalhos Set-Cookie com qualquer resposta.
Usuário agentes devem enviar Cookie pedido cabeçalhos, sujeito a outras
regras detalhadas a seguir, a cada pedido.

Uma origem servidor pode incluir vários Set-Cookie cabeçalhos em um
resposta. Note-se que um gateway poderia intervir várias vezes, tais
cabeçalhos em um único cabeçalho.

4.2.2 Sintaxe Set-Cookie

A sintaxe para o cabeçalho Set-Cookie resposta é

set-cookie = “Set-Cookie:” cookies
cookies = 1 # cookie
NOME cookie = “=” VALOR *(”;” cookie-av)
NOME attr =
VALOR = valor
cookie-av = “Comentar” “=” valor
| “Site” “=” valor
| “Max-Age” “=” valor
| “Caminho” “=” valor
| “Secure”
| “Versão” “=” 1 * DIGIT

Informalmente, os Set-Cookie resposta cabeçalho compreende o token Set -
Cookie:, seguido por uma lista separada por vírgulas de um ou mais cookies.
Cada cookie começa com um nome = valor par, seguido de zero ou mais
ponto e vírgula-separados dos pares valor-atributo. A sintaxe para
atributo de valor pares foi mostrado anteriormente. Os atributos específicos e
a semântica do seguinte modo os seus valores. O atributo NAME = VALOR -
valor par deve estar em primeiro lugar em cada um cookie. Os outros, quando presentes,
Pode ocorrer em qualquer ordem. Se um atributo aparece mais de uma vez em um
cookie, o comportamento é indefinida.

NAME = VALUE
Necessário. O nome do Estado informações ( “cookie”) é DENOMINAÇÃO,
eo seu valor é valor. Nomes que começam com US $ estão reservados para
outros usos e não deve ser utilizado por aplicações.
Kristol Standards Track & Montulli [Página 4]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
O valor é pouco transparente para o usuário e agente pode ser qualquer coisa a
origem servidor escolhe a enviar, possivelmente em um servidor-selecionados
codificação ASCII imprimíveis. “Opaca” implica que o conteúdo é de
interesse e relevância apenas para o servidor origem. O conteúdo
maio, na verdade, ser lido por qualquer um que analisa a Set-Cookie
cabeçalho.

Comentar comentar =
Opcional. Porque os cookies podem conter informações particulares sobre uma
utilizador, o cookie permite que um atributo origem servidor para o seu documento
destinados uso de um cookie. O usuário pode inspecionar as informações para
decidir se deseja iniciar ou prosseguir uma sessão com esse cookie.

Domínio = domínio
Opcional. O Domínio atributo especifica o domínio para o qual o
cookie é válido. Um domínio explicitamente especificado deve sempre começar
com um ponto.

Max-Age = delta-segundo
Opcional. O Max-Age atributo define o tempo de vida dos
cookie, em segundos. Delta-O segundo é um valor não-decimais
inteiro negativo. Após o delta-segundo decorrer segundo, o cliente
deve descartar o cookie. Um valor de zero significa que o cookie
deve ser rejeitada imediatamente.

Path = caminho
Opcional. O Caminho atributo especifica o subconjunto de URLs a
que este cookie se aplica.

Secure
Opcional. O Secure atributo (sem valor) direciona o usuário
Agente de utilizar apenas (não especificada) assegurar meios de contactar a origem
sempre que o servidor envia de volta este cookie.

O agente usuário (possivelmente sob o controle do usuário) podem determinar
qual o nível de segurança que considere adequadas para “garantir”
cookies. O Secure atributo deve ser considerada de segurança
aconselhamento do servidor para o usuário agente, indicando que está em
a sessão do interesse de proteger o cookie conteúdo.

Version = versão
Necessário. A Versão atributo, um decimal inteiro, identifica a
qual a versão do estado gestão especificação do cookie
conforma. Para esta especificação, Version = 1 se aplica.

Kristol Standards Track & Montulli [Página 5]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
4.2.3 Controladores cashing

Um servidor deve estar cientes origem do efeito de eventuais caching
de ambos os recursos e retornou a Set-Cookie cabeçalho. Caching
“público” documentos é desejável. Por exemplo, se o servidor origem
pretende utilizar um documento público, tais como uma “porta” como uma página
sentinela para indicar o início de uma sessão para a qual um Set -
Cookie resposta cabeçalho devem ser gerados, a página deve ser armazenada
em caches “pré-caducou” origem de modo a que o servidor irá ver mais
solicitações. “Private documentos”, por exemplo, aqueles que contêm
informações estritamente privado a uma sessão, não devem ser colocados em cache no
caches compartilhados.

Se o cookie é para ser usado por um único usuário, o Set-Cookie
cabeçalho não deve ser armazenada em cache. Um Set-Cookie cabeçalho que se destina a
ser partilhado por vários utilizadores podem estar em cache.

A origem servidor deve enviar os seguintes adicionais HTTP/1.1
cabeçalhos resposta, dependendo de circunstâncias:

* Para suprimir caching do cabeçalho Set-Cookie: Cache-controle: não -
cache = “set-cookie”.

e um dos seguintes procedimentos:

* Para suprimir cache de um documento privado em caches partilhada: Cache -
controle: privado.

* Para permitir o cache de um documento, e exigir que ele seja validado
antes de a devolver ao cliente: Cache-controle: deve-revalidar.

* Para permitir o cache de um documento, mas para exigir que os caches proxy
(agente usuário não caches) validar-lo antes de a devolver ao
client: Cache-control: proxy-revalidar.

* Para permitir o cache de um documento e solicitar que ele seja validado
antes de a devolver ao cliente (por “pré-termina-lo”):
Cache-control: max-age = 0. Nem todos os caches vai revalidar o
documento em todos os casos.

HTTP/1.1 servidores devem enviar Expira: old-data (em que data é um velho -
longa data no passado) sobre respostas contendo Set-Cookie resposta
cabeçalhos a menos que eles sabem para determinados (por meio fora da banda) que
não há downsteam HTTP/1.0 proxies. HTTP/1.1 servidores podem enviar
Cache-Control outras directivas que permitam a caching HTTP/1.1
proxies, além da Expira: old-data directiva; o Cache -
Controle directiva irá sobrepor-se ao Expira: old-data para HTTP/1.1
proxies.

Kristol Standards Track & Montulli [Página 6]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
4,3 User Agent papel

4.3.1 Interpretando Set-Cookie

O usuário faixa distinto agente mantém informações de estado que chega
através Set-Cookie resposta cabeçalhos origem de cada servidor (como
distinguidas por nome ou endereço IP e porto). O agente usuário
aplica estes padrões para atributos opcionais que estão faltando:

VersionDefaults a “velha cookie” comportamento como originalmente especificados por
Netscape. Veja o histórico seção.

Domínio Padrões para o pedido de acolhimento. (Note que não existe um ponto em
o início do pedido de acolhimento.)

Max-AgeThe comportamento padrão é a de descartar o cookie quando o usuário
Agente saídas.

Padrões caminho para o caminho do URL que gerou o pedido
Set-Cookie resposta, até, mas não incluindo, a
a maioria de direita /.

Secure Se ausente, o usuário poderá enviar o agente durante um cookie
inseguro canal.

4.3.2 Rejeitar Cookies

Para prevenir possíveis violações de segurança ou privacidade, um agente usuário
rejeita um cookie (não deve armazenar seus dados) se qualquer das
seguinte é verdadeiro:

* O valor para o Caminho atributo não é um prefixo do pedido -
URI.

* O valor para o Site não contém nenhum atributo ou incorporados pontos
não começar com um ponto.

* O valor para o pedido de acolhimento não correspondam ao domínio-Domínio
atributo.

* A pedido de acolhimento é um FQDN (não endereço IP) e tem a forma HD,
onde D é o valor do atributo de domínio, e H é uma string
que contém um ou mais pontos.

Exemplos:

* Um pedido de Set-Cookie-host yxfoo.com de Domínio =. foo.com
seria rejeitada, porque H é yx e contém um ponto.

Kristol Standards Track & Montulli [Página 7]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
* Um pedido de Set-Cookie-host x.foo.com de Domínio =. seria foo.com
ser aceite.

* Um Set-Cookie com Domínio =. com.br ou Domain =. com., Será sempre
rejeitadas, porque não há embutido dot.

* Um Set-Cookie com Domain = ajax.com serão rejeitadas, porque a
Valor de Domínio não comece com um ponto.

4.3.3 Gerenciamento de Cookie

Se um agente usuário recebe uma resposta cabeçalho Set-Cookie cujo nome é
o mesmo que um pré-existentes cookie, e cujo domínio e Path
atribuem valores exatamente (corda) correspondem às de uma pré-existentes
cookie, o novo cookie substitui o antigo. No entanto, se o Set -
Cookie tem um valor para Max-Idade do zero, os (antigos e novos) cookie é
descartados. Caso contrário cookies acumular até que expiram (recursos
licenciamento), momento em que eles são descartados.

Porque os agentes do utilizador ter finito espaço no qual os cookies para armazenar, eles
também pode descartar mais velhos cookies para criar espaço para mais novas, utilizando,
por exemplo, um mínimo de recém-algoritmo utilizado, juntamente com constrangimentos
sobre o número máximo de cookies que cada servidor pode definir origem.

Se um cabeçalho Set-Cookie resposta inclui um comentário atributo, o
agente usuário deve guardar essa informação em uma forma legível por humanos
com o cookie e deve exibir o comentário como parte de um texto
cookie inspecção interface de utilizador.

Usuário agentes deverão permitir que o usuário de controlar a destruição cookie. Um
- raramente utilizado cookie maio funcionar como um “dossier preferências” para a
aplicações de rede, e um usuário pode querer mantê-lo mesmo que seja
- recentemente-o menos utilizado cookie. Uma possível implementação seria
uma interface que permite o armazenamento permanente de um cookie através de uma
caixa (ou, inversamente, a sua destruição imediata).

Privacidade considerações ditar que o usuário tem considerável
controlo de gestão cookie. A seção contém mais PRIVACIDADE
informação.

4.3.4 Enviando para os Cookies Origem Server

Quando se envia uma solicitação para um servidor origem, o usuário envia um agente
Cookie pedido cabeçalho à origem servidor se ele tiver que são cookies
aplicável ao pedido, com base em

* O pedido de acolhimento;
Kristol Standards Track & Montulli [Página 8]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
* O pedido-URI;

* O cookie da idade.

A sintaxe para o cabeçalho é:

cookie = “Cookie:” cookie-versão
1 *((”;” | “,”) cookie-valor)
cookie-valor NAME = “=” o valor [ ";" caminho] [ ";" domínio]
cookie-versão = “$ Version” “=” valor
NOME attr =
VALOR = valor
path = “$ Path” “=” valor
domain = “$ Domínio” “=” valor

O valor do cookie-versão atributo deve ser o valor a partir do
Versão atributo, se for o caso, da correspondente Set-Cookie resposta
cabeçalho. Caso contrário, o valor de cookie-versão é 0. O valor para
atribuem o caminho deve ser o valor da senda atributo, se for o caso,
as correspondentes cabeçalho Set-Cookie resposta. Caso contrário, a
atributo deve ser omitidos na Cookie pedido cabeçalho. O
Valor para o domínio atributo deve ser o valor a partir do Domínio
atributo, se for o caso, as correspondentes cabeçalho Set-Cookie resposta.
Caso contrário, o atributo deve ser omitida a partir da solicitação Cookie
cabeçalho.

Note que não há qualquer comentário atributo no cabeçalho Cookie pedido
o que corresponde a um no cabeçalho Set-Cookie resposta. O usuário
agente não voltar a comentar a informação do servidor origem.

As seguintes regras aplicam-se a escolha aplicável a partir de valores de cookies
entre todos os cookies o usuário tem agente.

Domínio Seleção
A origem do servidor host totalmente qualificado, nome de domínio deve corresponder
Domínio do atributo do cookie.

Caminho Seleção
O Caminho atributo do cookie deve corresponder a um prefixo da
solicitar-URI.

Max-idade seleção
Os cookies que já expirou deveria ter sido descartado e, portanto,
não são enviadas a um servidor origem.

Kristol Standards Track & Montulli [Página 9]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
Se vários cookies satisfazem os critérios acima referidos, eles são ordenados em
Cookie o cabeçalho de tal ordem que aqueles com mais específicos Caminho atributos
preceder aqueles com menos específico. Ordenação em relação aos outros
atributos (e.g., Domain) é indeterminado.

Nota: para compatibilidade com versões anteriores, o separador no cabeçalho Cookie
É ponto e vírgula (;) em todo o lado. Um servidor também deve aceitar a vírgula (,)
como separador entre cookie-valores para a futura compatibilidade.

4.3.5 Enviando Cookies em verificar Transações

Os utilizadores devem ter controle sobre sessões, a fim de assegurar a privacidade.
(Ver secção PRIVACIDADE abaixo.) Para simplificar a implementação e para
impedir uma camada adicional de complexidade quando as garantias adequadas
Existem, no entanto, este documento faz uma distinção entre transacções que
são verificáveis e os que estão a verificar. A transação é
verificar se o usuário tem a possibilidade de rever o pedido prévio-URI
a sua utilização na operação. A operação é verificar se o
usuário não tiver essa opção. Verificar operações tipicamente
surgem quando um agente usuário automaticamente pedidos inlined ou incorporados
entidades ou quando se resolve reorientação (3XX) respostas de um
origem servidor. Normalmente a origem transacção, a transacção
que o usuário inicie, é verificável, e que a transação maio
directa ou indirectamente induzir o usuário a fazer verificar agente
transacções.

Quando se torna verificar uma transação, um agente deve permitir que um usuário
sessão somente se um cookie em um domínio D atributo foi enviada ou
recebeu a sua origem na operação, de tal forma que o nome do host no
URI-Pedido de verificar a operação de domain-jogos D.

Esta restrição impede um serviço malicioso autor de utilizar
verificar utilizador operações para induzir um agente para iniciar ou continuar
uma sessão com um servidor em um domínio diferente. A partida ou
continuação de tais sessões poderia ser contrária à privacidade
expectativas do usuário, e também poderia ser um problema de segurança.

Usuário agentes podem oferecer opções configuráveis que permitem que o usuário agente,
autónomo ou de qualquer programas que o usuário executa agente, a ignorar
a regra acima, enquanto estas sobrepor opções default para “off”.

Muitos agentes já atual usuário fornecer uma análise opção que teria
render muitas ligações verificáveis. Por exemplo, alguns agentes usuário exibir
o URL que seria referenciado para um determinado link quando o mouse
ponteiro é colocado sobre o link. O usuário pode, por conseguinte, determinar
saber se a visitar o site antes de provocar o browser para o fazer.
(Embora não seja aplicado ao usuário atual agentes, uma técnica semelhante
poderia ser utilizada para um botão usado para enviar um formulário - o usuário agente

Kristol Standards Track & Montulli [Página 10]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
poderiam apresentar as medidas a tomar caso o usuário que foram para selecionar
botão.) No entanto, mesmo esta não faria todos os links verificáveis, para
exemplo, ligações a carregado automaticamente imagens não é normalmente
sujeitas ao “rato” verificação.

Muitos agentes usuário também prever a possibilidade de um usuário para visualizar o HTML
fonte de um documento, ou para salvar a fonte para um arquivo externo onde
que podem ser vistas por um outro aplicativo. Embora tal opção não
proporcionar um mecanismo de revisão bruto, alguns utilizadores poderão não considerá-lo
aceitável para este fim.

Como um servidor de 4,4 Origem Interpreta o cabeçalho Cookie

Um usuário agente retorna grande parte da informação no cabeçalho Set-Cookie
a origem do servidor quando o Caminho de correspondências que atribuem um novo
solicitar. Sempre que receber um cookie header, o servidor deverá origem
tratar com cookies cujos nomes prefixo é de US $ especialmente, como um atributo
adjacentes para o cookie. O valor para tal, deve ser um nome
interpretado como aplicável aos lexically (da esquerda para a direita) mais recente
cookie cujo nome não têm o prefixo $. Se não houver nenhuma
cookie anterior, o valor aplica-se ao mecanismo de cookie como uma
inteiro. Por exemplo, considere o cookie

Cookie: $ Version = “1″; Cliente = “WILE_E_COYOTE”;
$ Path = “/ acme”

Versão $ aplica-se ao mecanismo de cookie como um todo (e dá a
número de versão para o mecanismo de cookie). $ Path é um atributo
cujo valor (/ acme) define o Caminho atributo que foi utilizado quando o
Cliente foi definida em um cookie Set-Cookie resposta cabeçalho.

4,5 cache proxy papel

Uma razão para separar o estado de informações tanto de uma URL e
documento conteúdo é o de facilitar o escalonamento que permite caching.
Para apoiar os cookies, um cache proxy deve obedecer essas regras já em
o HTTP especificação:

* Honra pedidos a partir do cache, se possível, com base em cache validade
regras.

* Pass, ao longo de um cookie no cabeçalho solicitar a qualquer pedido que o procurador
deve fazer de outro servidor.

* Voltar a resposta para o cliente. Set-Cookie incluir qualquer resposta
cabeçalho.

Kristol Standards Track & Montulli [Página 11]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
* Cache recebeu a resposta sujeita ao controlo do costume
cabeçalhos, como expirar, Cache-control: no-cache, e Cache -
controle: privado,

* Cache do Set-Cookie sujeito ao controlo do cabeçalho usual,
Cache-control: no-cache = “set-cookie”. (O cabeçalho Set-Cookie
Normalmente não deve ser armazenada em cache.)

Proxies não devem introduzir Set-Cookie (Cookie) cabeçalhos das suas próprias
no proxy respostas (pedidos).

5. EXEMPLOS

5,1 Exemplo 1

A maioria dos detalhes do pedido e resposta cabeçalhos foi omitido. Assumamos
o usuário não tem nenhum agente cookies armazenados.

1. User Agent -> Servidor

POST / acme / login HTTP/1.1
[formulário de dados]

Usuário identifica autodeterminação através de um formulário.

2. Servidor -> User Agent

HTTP/1.1 200 OK
Set-Cookie: Cliente = “WILE_E_COYOTE”; Version = “1″; Path = “/ acme”

Cookie reflete a identidade do usuário.

3. User Agent -> Servidor

POST / acme / pickitem HTTP/1.1
Cookie: $ Version = “1″; Cliente = “WILE_E_COYOTE”; $ Path = “/ acme”
[formulário de dados]

Usuário seleciona um item de “cesto”.

4. Servidor -> User Agent

HTTP/1.1 200 OK
Set-Cookie: Part_Number = “Rocket_Launcher_0001″; Version = “1″;
Path = “/ acme”

Cesto de contém um item.
Kristol Standards Track & Montulli [Página 12]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
5. User Agent -> Servidor

POST / acme / navegação HTTP/1.1
Cookie: $ Version = “1″;
Cliente = “WILE_E_COYOTE”; $ Path = “/ acme”;
Part_Number = “Rocket_Launcher_0001″; $ Path = “/ acme”
[formulário de dados]

Usuário seleciona navegação método de formulário.

6. Servidor -> User Agent

HTTP/1.1 200 OK
Set-Cookie: Transporte marítimo = “FedEx”; Version = “1″; Path = “/ acme”

Novo método de transporte marítimo reflecte cookie.

7. User Agent -> Servidor

POST / acme / processo HTTP/1.1
Cookie: $ Version = “1″;
Cliente = “WILE_E_COYOTE”; $ Path = “/ acme”;
Part_Number = “Rocket_Launcher_0001″; $ Path = “/ acme”;
Shipping = “FedEx”; $ Path = “/ acme”
[formulário de dados]

Usuário escolhe a processo judicial.

8. Servidor -> User Agent

HTTP/1.1 200 OK

A transação está completo.

O agente usuário faz uma série de pedidos sobre a origem servidor, após
cada um dos quais ela recebe um novo cookie. Todos os cookies têm o
Caminho e mesmo atributo (padrão) domínio. Devido ao facto de a solicitação URLs
todos têm / acme como um prefixo, e que corresponda à senda atributo, cada
pedido contém todos os cookies recebidos até agora.

5,2 Exemplo 2

Este exemplo ilustra o efeito do Caminho atributo. Todos
detalhes do pedido e resposta cabeçalhos foi omitido. Assumir a
agente usuário não tem cookies armazenados.

Imagine o usuário agente tenha recebido, em resposta a pedidos anteriores,
a resposta cabeçalhos

Kristol Standards Track & Montulli [Página 13]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
Set-Cookie: Part_Number = “Rocket_Launcher_0001″; Version = “1″;
Path = “/ acme”

e

Set-Cookie: Part_Number = “Riding_Rocket_0023″; Version = “1″;
Path = “/ acme / munição”

Um posterior pedido do agente para o usuário (mesmo) servidor para URLs
da forma / acme / munições / … deve incluir o seguinte pedido
cabeçalho:

Cookie: $ Version = “1″;
Part_Number = “Riding_Rocket_0023″; $ Path = “/ acme / munição”;
Part_Number = “Rocket_Launcher_0001″; $ Path = “/ acme”

Note que o nome = valor par para o cookie com o mais específico
Caminho atributo, / acme / munições, antes de chegar a um com o menor
Caminho atributo específico, / acme. Além disso note que o mesmo cookie
nome aparece mais de uma vez.

Um posterior pedido do agente para o usuário (mesmo) para um servidor URL
da forma / acme / peças / pedido deve incluir o seguinte cabeçalho:

Cookie: $ Version = “1″; Part_Number = “Rocket_Launcher_0001″; $ Path = “/ acme”

Aqui, segundo o cookie do Caminho atributo / acme / munição não é um prefixo
URL do pedido, / acme / peças /, de modo que o cookie não obtém
enviadas para o servidor.

6. APLICAÇÃO CONSIDERAÇÕES

Aqui nós especular sobre prováveis ou desejáveis detalhes para um servidor origem
que implementa gestão estatal.

6,1 Set-Cookie Conteúdo

Um servidor de conteúdos da origem provavelmente deverá ser dividida em disjoint
aplicação áreas, algumas das quais requerem o uso de Estado
informação. O pedido áreas podem ser distinguidos pela sua
URLs pedido. O cabeçalho Set-Cookie pode incorporar informações
sobre o pedido através do estabelecimento de áreas do Caminho para cada atributo
um.

A sessão informação pode, evidentemente, ser claro que o texto codificado ou
Descreve estado. No entanto, se ele cresce muito grande, ele pode tornar-se
pesadas. Por conseguinte, que poderão optar por um implementor para a sessão
informação a ser a chave para um servidor do lado dos recursos. Evidentemente, utilizando

Kristol Standards Track & Montulli [Página 14]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
uma base de dados gera alguns problemas que este estado de gestão
especificação foi concebido para evitar, a saber:

1. mantendo real estado do lado do servidor;

2. como e quando a recolher lixo de entrada do banco de dados, no caso de o
Agente utilizador termine a sessão, por exemplo, por sair.

6,2 Páginas Estado

Caching benefícios a escalabilidade da WWW. Por isso, é importante
para reduzir o número de documentos que tenham estado em lhes embutido
inerentemente. Por exemplo, se um cabaz de compras do estilo de candidatura
sempre exibe um usuário atual da cesta de conteúdos em cada página, os
páginas não pode ser armazenada, porque cada usuário do cabaz do conteúdo teria
ser diferente. Por outro lado, se cada página contém apenas um link
que permite ao usuário “Olhe meu cesto”, a página pode ser
cache.

6,3 Implementação Limites

Prático usuário agente implementações têm limites ao número e
tamanho de cookies que eles podem armazenar. Em geral, os agentes do utilizador ‘cookie
apoio não deve ter limites fixados. Eles deveriam esforçar para armazenar as
- muitos freqüentemente utilizado cookies possível. Além disso, utilizam-geral
os agentes do utilizador devem proporcionar cada uma das seguintes capacidades mínimas
individualmente, embora não necessariamente em simultâneo:

* Pelo menos 300 cookies

* Pelo menos 4096 bytes por cookie (tal como medida pelo tamanho do
caracteres que compõem o cookie não-terminal na sintaxe
descrição do cabeçalho Set-Cookie)

* Pelo menos 20 cookies per único hospedeiro ou nome do domínio

Usuário agências criadas para fins específicos ou para a limitada capacidade de
dispositivos devem proporcionar, pelo menos, 20 bolinhos de 4096 bytes, a fim de assegurar
que o usuário pode interagir com uma sessão à base de origem servidor.

As informações de um cabeçalho Set-Cookie resposta deve ser mantido em
sua totalidade. Se por alguma razão há insuficiência de espaço para armazenar
o cookie, ele deve ser descartado, não truncado.

As candidaturas deverão utilizar as poucas e tão pequenos quanto possível, os cookies, e
graciosamente eles devem lidar com a perda de um cookie.

Kristol Standards Track & Montulli [Página 15]

RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
6.3.1 ataques de negação de serviço

Os agentes do utilizador pode optar por fixar um limite superior sobre o número de cookies
para ser armazenada a partir de um determinado host ou nome de domínio ou sobre o tamanho da
cookie informação. Caso contrário um servidor malicioso poderia tentar
inundação um agente usuário com muitos cookies, cookies ou grandes, em sucessivas
respostas, o que força os cookies do utilizador agente tinha recebido
a partir de outros servidores. No entanto, os níveis mínimos especificados acima deverão ainda
ser apoiadas.

7. PRIVACIDADE

7,1 User Agent controle

Um servidor origem poderia criar um cabeçalho Set-Cookie para rastrear o caminho
de um utilizador através do servidor. Os usuários podem opor a esse comportamento como
intrusiva um acúmulo de informações, mesmo que a sua identidade é
Não evidente. (Identidade poderão tornar-se evidente quando um usuário subsequentemente
preenche um formulário que contém dados de identificação.) Este estado
Especificação de gestão, por isso, exige que um agente usuário dê
o usuário controle sobre um tal eventual intromissão, apesar de a
interface através do qual o usuário é dado esse controle é deixado
indeterminado. No entanto, os mecanismos de controlo serão fornecidos, pelo menos,
permitir que o usuário

* Para desativar completamente o envio de cookies e de poupança.

* A fim de determinar se uma sessão stateful está em andamento.

* Para controlar a poupança de um cookie em função do cookie’s
Domínio atributo.

Tal controlo poderá ser fornecida, por exemplo, pelos mecanismos

* A notificar o usuário quando o usuário agente está prestes a enviar um cookie
a origem do servidor, oferecendo a opção de não iniciar uma sessão.

* A exibir uma indicação visual que está em uma sessão stateful
progressos.

* Para permitir que o usuário decidir quais os cookies, se for o caso, devem ser salvos
quando o usuário conclui uma janela ou um agente usuário sessão.

* Para permitir que o usuário examinar o conteúdo de um cookie em qualquer momento.

Um usuário agente geralmente começa com a execução não lembrar estado
informação. It should be possible to configure a user agent never
to send Cookie headers, in which case it can never sustain state with

Kristol & Montulli          Standards Track                    [Page 16]

RFC 2109            HTTP State Management Mechanism        February 1997
an origin server.  (The user agent would then behave like one that is
unaware of how to handle Set-Cookie response headers.)

When the user agent terminates execution, it should let the user
discard all state information.  Alternatively, the user agent may ask
the user whether state information should be retained; the default
should be “no”.  If the user chooses to retain state information, it
would be restored the next time the user agent runs.

NOTE: User agents should probably be cautious about using files to
store cookies long-term.  If a user runs more than one instance of
the user agent, the cookies could be commingled or otherwise messed
up.

7.2  Protocol Design

The restrictions on the value of the Domain attribute, and the rules
concerning unverifiable transactions, are meant to reduce the ways
that cookies can “leak” to the “wrong” site.  The intent is to
restrict cookies to one, or a closely related set of hosts.
Therefore a request-host is limited as to what values it can set for
Domain.  We consider it acceptable for hosts host1.foo.com and
host2.foo.com to share cookies, but not a.com and b.com.

Similarly, a server can only set a Path for cookies that are related
to the request-URI.

8.  SECURITY CONSIDERATIONS

8.1  Clear Text

The information in the Set-Cookie and Cookie headers is unprotected.
Two consequences are:

1.  Any sensitive information that is conveyed in them is exposed
to intruders.

2.  A malicious intermediary could alter the headers as they travel
in either direction, with unpredictable results.

These facts imply that information of a personal and/or financial
nature should only be sent over a secure channel.  For less sensitive
information, or when the content of the header is a database key, an
origin server should be vigilant to prevent a bad Cookie value from
causing failures.
Kristol & Montulli          Standards Track                    [Page 17]

RFC 2109            HTTP State Management Mechanism        February 1997
8.2  Cookie Spoofing

Proper application design can avoid spoofing attacks from related
domains.  Consider:

1.  User agent makes request to victim.cracker.edu, gets back
cookie session_id=”1234″ and sets the default domain
victim.cracker.edu.

2.  User agent makes request to spoof.cracker.edu, gets back
cookie session-id=”1111″, with Domain=”.cracker.edu”.

3.  User agent makes request to victim.cracker.edu again, and
passes

Cookie: $Version=”1″;
session_id=”1234″;
session_id=”1111″; $Domain=”.cracker.edu”

The server at victim.cracker.edu should detect that the second
cookie was not one it originated by noticing that the Domain
attribute is not for itself and ignore it.

8.3  Unexpected Cookie Sharing

A user agent should make every attempt to prevent the sharing of
session information between hosts that are in different domains.
Embedded or inlined objects may cause particularly severe privacy
problems if they can be used to share cookies between disparate
hosts.  For example, a malicious server could embed cookie
information for host a.com in a URI for a CGI on host b.com.  User
agent implementors are strongly encouraged to prevent this sort of
exchange whenever possible.

9.  OTHER, SIMILAR, PROPOSALS

Three other proposals have been made to accomplish similar goals.
This specification is an amalgam of Kristol’s State-Info proposal and
Netscape’s Cookie proposal.

Brian Behlendorf proposed a Session-ID header that would be user-
agent-initiated and could be used by an origin server to track
“clicktrails”.  It would not carry any origin-server-defined state,
however.  Phillip Hallam-Baker has proposed another client-defined
session ID mechanism for similar purposes.
Kristol & Montulli          Standards Track                    [Page 18]

RFC 2109            HTTP State Management Mechanism        February 1997
While both session IDs and cookies can provide a way to sustain
stateful sessions, their intended purpose is different, and,
consequently, the privacy requirements for them are different.  A
user initiates session IDs to allow servers to track progress through
them, or to distinguish multiple users on a shared machine.  Cookies
are server-initiated, so the cookie mechanism described here gives
users control over something that would otherwise take place without
the users’ awareness.  Furthermore, cookies convey rich, server-
selected information, whereas session IDs comprise user-selected,
simple information.

10.  HISTORICAL

10.1  Compatibility With Netscape’s Implementation

HTTP/1.0 clients and servers may use Set-Cookie and Cookie headers
that reflect Netscape’s original cookie proposal.  These notes cover
inter-operation between “old” and “new” cookies.

10.1.1  Extended Cookie Header

This proposal adds attribute-value pairs to the Cookie request header
in a compatible way.  An “old” client that receives a “new” cookie
will ignore attributes it does not understand; it returns what it
does understand to the origin server.  A “new” client always sends
cookies in the new form.

An “old” server that receives a “new” cookie will see what it thinks
are many cookies with names that begin with a $, and it will ignore
them.  (The “old” server expects these cookies to be separated by
semi-colon, not comma.)  A “new” server can detect cookies that have
passed through an “old” client, because they lack a $Version
attribute.

10.1.2  Expires and Max-Age

Netscape’s original proposal defined an Expires header that took a
date value in a fixed-length variant format in place of Max-Age:

Wdy, DD-Mon-YY HH:MM:SS GMT

Note that the Expires date format contains embedded spaces, and that
“old” cookies did not have quotes around values.  Clients that
implement to this specification should be aware of “old” cookies and
Expires.
Kristol & Montulli          Standards Track                    [Page 19]

RFC 2109            HTTP State Management Mechanism        February 1997
10.1.3  Punctuation

In Netscape’s original proposal, the values in attribute-value pairs
did not accept “-quoted strings.  Origin servers should be cautious
about sending values that require quotes unless they know the
receiving user agent understands them (i.e., “new” cookies).  A
(”new”) user agent should only use quotes around values in Cookie
headers when the cookie’s version(s) is (are) all compliant with this
specification or later.

In Netscape’s original proposal, no whitespace was permitted around
the = that separates attribute-value pairs.  Therefore such
whitespace should be used with caution in new implementations.

10.2  Caching and HTTP/1.0

Some caches, such as those conforming to HTTP/1.0, will inevitably
cache the Set-Cookie header, because there was no mechanism to
suppress caching of headers prior to HTTP/1.1.  This caching can lead
to security problems.  Documents transmitted by an origin server
along with Set-Cookie headers will usually either be uncachable, or
will be “pre-expired”.  As long as caches obey instructions not to
cache documents (following Expires: <a date in the past> or Pragma:
no-cache (HTTP/1.0), or Cache-control: no-cache (HTTP/1.1))
uncachable documents present no problem.  However, pre-expired
documents may be stored in caches.  They require validation (a
conditional GET) on each new request, but some cache operators loosen
the rules for their caches, and sometimes serve expired documents
without first validating them.  This combination of factors can lead
to cookies meant for one user later being sent to another user.  The
Set-Cookie header is stored in the cache, and, although the document
is stale (expired), the cache returns the document in response to
later requests, including cached headers.

11.  ACKNOWLEDGEMENTS

This document really represents the collective efforts of the
following people, in addition to the authors: Roy Fielding, Marc
Hedlund, Ted Hardie, Koen Holtman, Shel Kaphan, Rohit Khare.

Kristol & Montulli          Standards Track                    [Page 20]

RFC 2109            HTTP State Management Mechanism        February 1997
12.  AUTHORS’ ADDRESSES

David M. Kristol
Bell Laboratories, Lucent Technologies
600 Mountain Ave.  Room 2A-227
Murray Hill, NJ  07974

Phone: (908) 582-2250
Fax: (908) 582-5809
EMail: dmk@bell-labs.com
Lou Montulli
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA  94043

Phone: (415) 528-2600
EMail: montulli@netscape.com

1. Os consumidores esperam que as suas compras sejam sociais

A essência do ser humano é ser social e compartilhar informações. O conceito da sabedoria das multidões é absolutamente poderoso e deve ser respeitado. Joel alerta para o fato de que um review negativo influência muito mais nas vendas do que uma crítica positiva.  Por que isso? Porque tudo o que fazemos é social. As pessoas compram porque é social.

2. Interações reais por pessoas reais

Lembramos aqui uma famosa citação de Eckart Walter, que foi VP of Product Management do Yahoo! Search, que ilustra perfeitamente este tópico: “Já não navegamos mais à toa na internet, lendo, ouvindo ou assistindo. O que fazemos é compartilhar, socializar, colaborar e, acima de tudo, criar”. Eu chamo atenção para o verbo criar. Quando fazemos o consumidor online interagir com as lojas virtuais ao ponto de criar alguma coisa dentro do site, seja uma comunidade, um pacote de produtos, um encontro, uma marca, ele muda de lado e passa a vestir a camisa da própria empresa, sendo mais do que um cliente fiel.

3. O futuro é agora. Conheça o envolvimento atual do consumidor

Joel usa como exemplo um aplicativo chamado SnapTell, que permite que você tire uma foto de um produto – por exemplo, um livro sobre uma mesa de café – e esse aplicativo, em seguida, mostra todos os lugares em que você pode comprá-lo online, ordenado por preço, com comentários, além de mostrar lojas físicas próximas que também possuem o livro para venda. Mas ele alerta: “Isso não é o futuro, isso é agora. Este é o ambiente atual do consumidor”.

4. Vá onde seu cliente está. E envolva!

É extremamente importante identificar o seu cliente e adequar a sua estratégia de mídia social conforme as necessidades de cada um, sem receita de bolo. Joel gosta muito do modelo da BestBuy no Facebook, que permite ao consumidor realizar as compras sem sair do site, assim como acontece com a BestBuy Express física em diversos aeroportos e locais públicos nos EUA. Aqui no Brasil, já temos cases semelhantes, como Fan Shop da Privalia no Facebook. Vale a visita aos 2 cases.

5. Não se trata de números.

Não se importe com a quantidade de fãs que você tem ou quantos seguidores você possui no Twitter. Concentre-se em conhecer realmente os seus consumidores. As pessoas querem fazer parte da comunidade. Identifique as que amam a sua marca e descubra uma maneira de se conectar com elas. Comece pequeno, mas conheça sua comunidade

1. Seja claro ao expor o preço do produto e o frete. Não esconda nem manipule o preço para iludir os clientes. Destaque todos os custos que fazem parte daquela compra, tanto em vitrines quanto no carrinho de compras.
2. Incentive os seus clientes com frete grátis ou descontos promocionais. Comunique os benefícios em diferentes momentos da navegação na loja Virtual, não restrinja apenas à página principal. O cliente pode não ser impactado logo na primeira vez que vir os incentivos e sim nas demais.
3. Ouça seu cliente e tente entender o que você pode fazer para ajudá-lo a comprar. Ligue ou envie email para os clientes que finalizaram suas compras e veja os motivos que o fizeram comprar na sua loja. Fale também com aqueles que estão cadastrados, mas nunca fizeram uma compra ou não compraram nada há mais de um ano.
4. Busque sempre a recuperação de vendas virtuais (boletos vencidos, pedidos negados, entre outros, que podem ser recuperados).
5. No momento de finalizar o pedido, não desvie a atenção do cliente para outros lugares. Analise com cuidado os elementos da página do produto e todo o processo de fechamento da compra.
6. Transmita segurança: desde um número de telefone para contato ou um atendimento online, até as melhores práticas de segurança. Deixe em locais visíveis para o cliente e não somente no rodapé da loja Online.
7. Use e abuse das fotos e vídeos. No comércio eletrônico, os clientes compram a imagem de um produto.
8. Direcione a navegação dando ênfase nos botões que levam o cliente ao próximo passo. Ajude e guie o cliente. Se não quer ajudar, pelo menos, não atrapalhe.
9. Utilize um super banner na página inicial e caracterize os departamentos com imagens. Mostre seus benefícios e produtos com maior destaque.
10. Use a opinião do cliente para expor a qualidade e a experiência com o seu produto. Produtos avaliados por clientes que compraram trazem mais resultado.

A expressão software factory – fábrica de software em inglês – foi usada pela primeira vez na década de 60. Popularizada apenas nos anos 90, define basicamente a ideia de aplicar conceitos da indústria em geral em ambientes de desenvolvimento de software, de forma a aumentar a produtividade e diminuir prazos e custos, tornando o processo mais independente do fator humano.

Apesar da expressão ‘fábrica’, o processo de criação de uma ferramenta é bem complexo. A fábrica de software cria um produto sob medida para cada cliente e utiliza em suas operações indicadores de qualidade e de produtividade em cada etapa do ciclo de desenvolvimento.

Alguns fatores contribuíram para o crescimento deste serviço, que surgiu para atender novas necessidades do mercado de TI. Entre estes estão a consolidação das técnicas de engenharia de software, o refinamento dos ambientes de desenvolvimento, a alta competitividade do mercado, o aumento da demanda por software e a tendência à terceirização de serviços.

Grandes empresas de TI têm suas próprias fábricas de software, no entanto o mais comum é que este serviço seja terceirizado. Com um mercado consumidor de TI cada vez mais exigente quanto aos aspectos de produtividade, custo e qualidade, as organizações fornecedoras têm procurado se transformar buscando um novo modelo, que supra com eficiência estas necessidades.

Entre os serviços prestados por uma fábrica de software estão o desenvolvimento de sistemas ou módulos, integração de aplicativos, manutenção de programas, incorporação de novas tecnologias, conversão de aplicativos para ambiente web, melhorias de performance e desenvolvimento de web services.

Como é a fábrica que realiza todo o processo, a empresa não precisa se preocupar com infraestrutura, nem de software e nem de hardware, não é necessário disponibilizar espaço e nem profissionais para realizar o serviço, o investimento é pré-definido, portanto não há custos extras ao longo do projeto, e tudo isso com o estabelecimento de um prazo de entrega. Esse é o grande diferencial da fábrica, o cliente não se preocupa com a gestão, apenas solicita o software.

Cada empresa tem uma necessidade específica, mas muitos processos são semelhantes. Por isso, uma fábrica que tenha diversos objetos que possam ser montados de acordo com as particularidades de cada empresa consegue entregar o pedido com maior rapidez. Além disso, como cada componente já foi testado diversas vezes, o resultado é em um produto final com melhor qualidade e custo reduzido.

Para ter um funcionamento adequado, há a necessidade de dividir a fábrica em alguns setores: de atendimento aos clientes, que negocia e especifica as necessidades da área usuária; de planejamento e controle da produção, que faz a alocação dos recursos, estabelece os prazos de desenvolvimento e a definição dos objetos a serem utilizados ou desenvolvidos; de produção, que faz a montagem da aplicação; e de qualidade e garantia, que verifica se o produto final atende as especificações exigidas.

Além de ter esses setores funcionando em conformidade é fundamental para o sucesso de uma fábrica de software é o gerenciamento dos recursos humanos e metodologia de trabalho.

Nana Korobi Ya Oki
Esta é uma frase japonesa antiga, que expressa exatamente o que uma pessoa que quer crescer, progredir, se tornar melhor deve saber: “Cair sete vezes, levantar oito”.

Estamos cada vez mais acostumados às facilidades do mundo moderno, Fast Food, celulares de última geração, automóveis que estacionam sozinhos, produtos eletrônicos que respondem ao toque ou um simples comando de voz.  O que se precisa entender é que isto tudo é muito bom no nosso dia a dia, mas existem coisas que para evoluirmos não há atalhos nem facilidades.
Mais do que se preocupar em tentar não sofrer ou buscar um “jeitinho” para alcançar os resultados sem esforço, o ser humano precisa aprender a lhe dar com as dificuldades e com suas próprias pernas vencer os obstáculos.  Se cair, ao invés de ficar se lamentando e tendo dó de si mesmo, lembre-se que os vencedores também caem, mas são os perdedores que não se levantam.  Não temos total controle sobre os percalços da vida e em muitas vezes somos postos em testes, uma pequena decisão pode mudar o rumo dos acontecimentos. Podemos nos enfurecer, reclamar, procurar um culpado, evidenciar tudo o que de ruim aconteceu ou podemos ver a melhor forma de resolver o problema. Energia negativa nunca atrairá energia positiva, fato.
Devemos sempre lembrar que nada é mais fácil para ninguém e que os obstáculos existem para todos. Todos os grandes homens da história em algum período de suas vidas caíram, mas o que os tornou grandes foi a capacidade de levantar e superar os obstáculos. Não somos inferiores a ninguém, tão pouco devemos ter um sentimento de auto piedade. Somos todos grandes por dentro e precisamos acreditar em nós mesmos para poder se mover e levantar. Tudo neste mundo é proporcional, por isso quanto maior for o seu sonho, maiores também serão os obstáculos, as dificuldades e as quedas serão inevitáveis. Isto é ruim? Claro que não, afinal de contas, quanto vale seus sonhos?
Nunca culpe ninguém por sua queda e agradeça pela oportunidade de poder se levantar.  Busque a elevação espiritual, respeite o próximo, não guarde rancor, pense positivo e vamos construir um mundo melhor!!!!!
GANBARIMASHOU!!!!!

Por: Akira Saito

Este é o registro de uma ação da Brastemp realizada através de 11 estacões de rádio de São Paulo. As rádios trasmitiram simultaneamente o spot Sorriso, que convidava os motoristas a sorrir para o motorista ao lado.

Hoje tive esse erro depois de mudar a hora do servidor do TFS:

TF54000: Cannot update data because the server clock may have been set incorrectly. Contact your Team Foundation Server Administrator.

Aconteceu isso porque ele criou alguns changesets que ficaram com a data depois da data do computador.

Para resolver não foi o mais recomendado(Leia-se:  faça um backup antes) ,mas:
delete from tbl_Changeset where CreationDate > getdate()

Ao planejar o empreendimento online, as cores relacionadas ao logotipo e ao design em geral devem ser escolhidas para representar sua loja diante da necessidade do consumidor.

Entendendo o perfil do seu cliente, torna-se mais simples destacar as cores primordiais no layout da loja virtual para fidelizá-lo.

Não é à toa que grandes marcas despertam determinadas sensações em seus consumidores e atraem mais clientes a todo momento; as cores influenciam diretamente no resultado das vendas, pois estimulam os consumidores de forma positiva ou negativa.

Ao fazer a escolha das cores que destacarão o seu e-commerce, é preciso ignorar os gostos pessoais e focar em seu cliente. O poder das cores é ligado à percepção das pessoas, por isso, sofre variações de acordo com fatores como idade, sexo e cultura. Logo, não basta escolher às cegas, é preciso ter referências. Por exemplo:

• Vermelho: Transmite energia, força. É destinado a um público mais jovem, possui o aspecto e a sensação de urgência, por isso, é comumente apresentado em promoções e descontos;

• Amarelo: É a cor que transmite felicidade e alegria. É muito utilizada para atrair a atenção dos consumidores;

• Laranja: Compartilha firmeza, coragem e comunicação. Estimula a ação;

• Rosa: Provoca a sensação de feminilidade, romantismo, intimidade. É usado para a comunicação direta com o público feminino;

• Roxo: É tido como misterioso e relaxante. Normalmente é utilizado em produtos para saúde contra envelhecimento, desodorantes e perfumes;

• Azul: Transmite tranquilidade, amor, confiança e segurança. É indicado para os públicos: infantil e de mais idade;

• Verde: Estimula à positividade, à saúde, ao dinheiro e ao crescimento. Tem o foco em um público mais esportista e/ou pessoas que buscam um estilo de vida mais saudável.

Levando em consideração informações divulgadas por empresas especialistas em pesquisa, em que 42% dos consumidores avaliam a qualidade da loja virtual através de seu design e que a cor certa de acordo com o público, aumenta em até 80% o reconhecimento da marca; conclui-se que vale à pena pensar e escolher de maneira precisa as cores que identificarão sua empresa na internet.

Anúncios em vídeo e localizados em sites de pesquisas são os formatos de publicidade digital mais propensos a inspirar ações do consumidor, de acordo com pesquisa realizada em agosto de 2011 pelo Internet Advertising Bureau (IAB). Dados do estudo “Affluent Consumers in a Digital World” indicam que o 41% dos consumidores que visualizaram anúncios em vídeo e de sites de pesquisas tomaram algum tipo de ação resultante de publicidade deste tipo nos últimos seis meses.

Anúncios em emails e banners aparecem em segundo lugar no percentual de inspiração de ação dos clientes, com 37% cada, seguidos por anúncios de mídias sociais (28%) e de dispositivos móveis (17%). No total, 59% dos consumidores que visualizaram anúncios digitais realizaram algum tipo de ação nos últimos seis meses.

Para cada tipo de anúncio, a ordem de classificação das ações tomadas por clientes é praticamente a mesma, com algumas exceções. No geral, 45% dos consumidores que visualizaram anúncios digitais clicaram em algum deles, 38% visitaram o site de um anunciante, 28% pesquisou por algum produto ou serviço online, 18% se tornou fã em rede social de algum anunciante, e 17% procuraram um varejista local.

Quando os consumidores foram questionados sobre qual tipo de anúncios são mais propensos a prender a sua atenção na internet, características relacionadas a sua relevância estavam entre as mais populares. Isto inclui anúncios com conteúdo relevante relacionado ao da página inicial no qual navegam (33%), mesmo percentual alcançado por anúncios relevantes sobre bens que estejam pensando em comprar, seguidos por anúncios relevantes para a localidade onde vivem ou estão (30%) e anúncios baseados na idade, gênero ou renda do consumidor (29%).

Consumidores considerados ricos – aquele com renda familiar de mais de US$ 100,000 – são ligeiramente mais propensos que o público em geral a prestar atenção em anúncios relevantes relacionados ao conteúdo de sua web page, aos produtos em que pensam comprar e aos relacionados a localização, mas por outro lado são um pouco menos propensos a prestar atenção em anúncios relevantes relacionados ao sexo, idade e renda dos indivíduos.

Além disso, anúncios engraçados/inesperados são de interesse de 30% do total dos consumidores, sejam eles ricos ou não.

Curiosamente, consumidores ricos são mais propensos a visualizar anúncios online que os façam se sentir desconfortável, pois eles sabem mais e também compartilham mais informações do que a média sobre ele com outros usuários para obter uma experiência online personalizada. 29% dos consumidores ricos já se sentiram desconfortáveis com anúncios que visualizam, valor 3% maior do que os 28% da média geral.

Entretanto, 32% deles estão normalmente dispostos a compartilhar informações, 23% a mais do que os 26% de média geral. De acordo com a pesquisa, os consumidores ricos compreendem atualmente a 21% das famílias americanas, que detêm uma fatia de 70% da riqueza dos consumidores e gastam em média 3,2 vezes mais em compras que os outros americanos.

85% dos adultos norte-americanos que navegam na internet visualizaram algum anúncio digital de qualquer tipo nos últimos sete dias, de acordo com outro estudo que indicou que os americanos ricos o fizeram a uma taxa um pouco maior (88%) do que os demais americanos (84%)

Se o e-Bit  estiver certo, o comércio eletrônico deverá ter encerrado o primeiro semestre de 2011 com um faturamento de R$ 8,8 bilhões, o que representa mais do que todas as vendas somadas em 2008 (R$ 8,2 bilhões). Os números mostram a força e o crescimento do setor, que deve chegar aos R$ 20 bilhões até o final do ano.

Com o mercado em expansão, é natural que as pequenas e médias empresas se sintam estimuladas a investir neste canal de vendas, na esperança de aproveitar o momento de explosão do e-commerce. No entanto, o comércio eletrônico não traz apenas oportunidades.

Recebo semanalmente várias solicitações de empresários dos mais diversos segmentos interessados em investir em soluções de e-commerce. Todos querem saber todos os detalhes sobre os recursos da plataforma, segurança, gestão dos estoques, sistema de pagamentos, atualização de produtos, preço e prazo de implementação. Ninguém pergunta sobre como promover a loja ou atrair consumidores. Poucos se mostram interessados quando eu faço esse questionamento, como se estivesse falando sobre um assunto sem relação nenhuma com o que precisam.

A preocupação com a promoção e a publicidade só aparece em um segundo momento, quando a loja já está no ar mas sem o índice de visitações nem de compras esperado. É quando surgem também as dúvidas: o que estou fazendo de errado? Por que meu concorrente vende mais? Por que a loja dele aparece na frente da minha no Google? Mas até chegar a este ponto a empresa talvez já tenha perdido tempo e dinheiro que poderiam ter sido investidos na promoção e publicidade que a diferenciariam.

Conscientizar-se de que o “aparecer” é tão importante quanto o “estar” na internet é o maior desafio da PME para tornar sua operação de e-commerce relevante para os negócios. Afinal, de pouco adianta ter uma loja bem estruturada se o cliente não sabe que ela existe.

Outro engano comum é considerar que basta investir em publicidade para aparecer e ter retorno. A loja pode até se tornar conhecida, mas será que isso é suficiente para persuadir o potencial cliente a comprar?

Para começar a resolver estas questões de destacar sua operação de e-commerce no mercado, há seis pontos essenciais que precisam ser levados me consideração:

1. Aprenda como o seu cliente pensa: Atualmente as empresas medem resultados usando apenas dois indicadores: taxa de conversão e número de transações. É uma forma muito limitada de avaliação pois é como se observasse apenas a ponta de um iceberg. Na verdade o consumidor passa por várias etapas para realizar uma compra na internet. Ele pesquisa produtos, marcas e preços, escolhe e compara as condições oferecidas pelas lojas, busca opinião de outros clientes na própria loja ou nas redes sociais. E cada um desses procedimentos tem peso em sua decisão em relação à escolha do item e da loja que vai preferir.

2. Domine os fatores-chave de sucesso: Fator-chave de sucesso é o aspecto essencial para um negócio ser bem sucedido em sua área de atuação. No e-commerce, três fatores-chave são preço competitivo, prazo de entrega e comodidade para pagamento. Sem eles não há chance de concorrer no mercado, então invista para estar pelo menos no mesmo patamar que os seus concorrentes nestes indicadores.

Aproveite todas as oportunidades de contato com o cliente para medir o seu grau de satisfação nestes três aspectos por meio de uma rápida enquete e aprimore seus fatores-chave de sucesso.

3. Crie um diferencial: Se a sua empresa se destacar em um ou mais fatores-chave de sucesso em relação aos concorrentes e ao mercado em geral, parabéns. Você obteve um diferencial e deve explorá-lo para se tornar uma referência e atrair consumidores para a sua loja. Oferece o preço mais baixo, a entrega mais rápida ou as melhores condições de pagamento do mercado? Não tenha vergonha de escancarar estes benefícios no site.

Mesmo não sendo o mais barato, o mais rápido ou que aceita qualquer pagamento, sua empresa pode criar um diferencial. Pode ser a única em seu segmento a ter maior variedade de uma determinada categoria, oferecer produtos exclusivos, fazer as promoções mais criativas.

Avalie o mercado, perfil do seu público-alvo e a sua loja e descubra quais diferenciais você pode explorar.

4. Marque presença na internet: Até aqui você se dedicou a criar bons motivos para os consumidores visitarem e comprarem na sua loja. Agora precisamos divulgar que ela existe e a melhor forma de fazer isso é por meio da publicidade online. O primeiro passo é investir onde poderá se encontrado com mais facilidade: em buscadores como Google, Yahoo! e MSN Bing. Afinal, a primeira coisa que a maioria das pessoas faz quando precisa de alguma coisa na internet é acessar um desses sites. Estar nas primeiras colocações das pesquisas significa grandes chances de atrair clientes em potencial para o seu site.

Há duas formas de fazer isso. Na chamada otimização em sites de busca (SEO), a aplicação de uma série de técnicas fazem seu site ser visto como mais relevante em relação a outros e assim conseguir as melhores colocações na pesquisa de uma determinada palavra-chave. Na publicidade em sites de busca (SEM), você investe em links patrocinados (um tipo de classificado ao lado dos resultados da pesquisa) ou redes de conteúdo (seus anúncios aparecem junto com o conteúdo relacionado aos seus produtos em sites, blogs e portais parceiros do buscador.

Há diversas formas de publicidade online, mas o SEM e o SEO são as mais indicadas para começar a promover a sua loja.

5. Relacione-se com seus clientes: Mesmo que esteja interessado em um produto, você já sai comprando na primeira abordagem do vendedor? É muito provável que não. Porém, no papel de vendedor da loja virtual, é isso que você espera de todo visitante que entra no seu site, não é mesmo?

Até agora viemos preparando o terreno. A pessoa pesquisou pelo produto, encontrou o seu site, achou o diferencial interessante e resolver visitá-lo. Gostou das ofertas, dos produtos e das informações e…resolveu não comprar desta vez. O que você faz?

Se for um bom e atencioso vendedor, mesmo se depois de toda sua ajuda o cliente optou por não efetivar a compra, você deixou o seu cartão para ele se lembrar da loja. Podemos fazer o mesmo por meio da newsletter. No e-commerce, o e-mail de um cliente vale ouro. Tenha ou não feito a compra no momento, ao deixar o seu e-mail para receber a newsletter ele está autorizando você a estabelecer um relacionamento com a sua loja.

Por isso o e-mail marketing é considerado hoje como a principal ferramenta de relacionamento com os consumidores. Desde que, é claro, seja bem utilizada. Para gerar resultados efetivos, esqueças as listas e as mensagens genéricas que só geram spams para se dedicar a construir uma base de e-mails de pessoas realmente interessadas nas ofertas da sua loja. Use ferramentas de disparo de e-mails que forneçam relatórios pormenorizados. Monitore o que as pessoas se interessaram, faça uma segmentação e personalize suas mensagens de acordo com esses interesses.

É muito mais trabalhoso, mas os resultados compensam. No Brasil, há casos de empresas que aumentaram a taxa de cliques por e-mail aberto (indicador de interesse pelas ofertas) de 0,2% para 19%.

Tenha consciência de que e-mail marketing é uma forma de relacionamento e não venda direta. Invista em uma base de dados e em tecnologias que possibilitem transformar esse relacionamento em vendas, e não em spams.

6. Aprenda com os líderes de mercado: Acompanhe sistematicamente os grandes portais de e-commerce tanto no Brasil quanto no exterior. Assine as newsletters, siga-as nas redes sociais, visite e navegue nos sites semanalmente em busca de novidades.

Estas empresas investem pesadamente no aprimoramento da usabilidade, em novos recursos e formas de relacionamento e, se você souber avaliar, podem ser uma excelente fonte de aprendizado para a sua própria loja