Configurar Aplicativos Web Estáticos do Azure

Defina a configuração dos Aplicativos Web Estáticos do Azure no arquivo staticwebapp.config.json, que controla as seguintes configurações:

• Roteamento
• Autenticação
• Autorização
• Regras de fallback
• Substituições de resposta HTTP
• Definições de cabeçalho HTTP global
• Tipos MIME personalizados
• Rede

Local do arquivo

O local recomendado para o staticwebapp.config.json está na pasta definida como o app_location no arquivo de fluxo de trabalho. No entanto, você pode colocar o arquivo em qualquer subpasta dentro do conjunto de pastas como o app_location. Além disso, se houver uma etapa de build, você deve garantir que a etapa de build gere o arquivo para a raiz do output_location.

Confira o exemplo do arquivo de configuração para ver detalhes.

Rotas

Você pode definir regras para uma ou mais rotas em seu aplicativo Web estático. As regras de rota permitem restringir o acesso a usuários em funções específicas ou executar ações como redirecionamento ou reescrita. As rotas são definidas como uma matriz de regras de roteamento. Confira o exemplo de arquivo de configuração para obter exemplos de uso.

• As regras são definidas na matriz routes, mesmo se você tiver apenas uma rota.
• As regras são avaliadas na ordem em que aparecem na matriz de routes.
• A avaliação da regra é interrompida na primeira correspondência. Uma combinação ocorre quando a propriedade route e um valor na matriz methods (se especificado) corresponderem à solicitação. Cada solicitação pode corresponder a no máximo uma regra.

As preocupações de roteamento se sobrepõem significativamente com os conceitos de autenticação (identificação do usuário) e autenticação (atribuição de capacidades ao usuário). Certifique-se de ler o guia de autenticação e autorização, juntamente com este artigo.

Definir rotas

Cada regra é composta por um padrão de rota, juntamente com uma ou mais das propriedades de regra opcionais. As regras de rota são definidas na matriz routes. Confira o exemplo de arquivo de configuração para obter exemplos de uso.

Propriedade de regra	Obrigatório	Valor padrão	Comentário
route	Sim	n/d	O padrão de rota solicitado pelo chamador. Há suporte para curingas no final dos caminhos de rota. Por exemplo, a rota /admin* corresponde a qualquer rota que comece com /admin.
methods	Não	Todos os métodos	Define uma matriz de métodos de solicitação que correspondem a uma rota. Os métodos disponíveis incluem: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE e PATCH.
rewrite	Não	n/d	Define o arquivo ou caminho retornado da solicitação. É mutuamente exclusivo para uma regra redirect. Regras de regeneração não alteram o local do navegador. Os valores precisam ser relativos à raiz do aplicativo.
redirect	Não	N/D	Define o destino de redirecionamento do arquivo ou caminho para uma solicitação. É mutuamente exclusivo para uma regra rewrite. As regras de redirecionamento alteram o local do navegador. O código de resposta padrão é um 302 (redirecionamento temporário), mas você pode substituí-lo por um 301 (redirecionamento permanente).
statusCode	Não	301 ou 302 para redirecionamentos	O código de status HTTP da resposta.
headers	Não	N/D	Conjunto de cabeçalhos HTTP adicionado à resposta. Os cabeçalhos específicos de rota substituem globalHeaders quando o cabeçalho específico de rota é o mesmo que o cabeçalho global que está na resposta. Para remover um cabeçalho, defina o valor dele como uma cadeia de caracteres vazia.
allowedRoles	Não	anônimo	Define uma matriz de nomes de função necessários para acessar uma rota. Os caracteres válidos incluem a-z, A-Z, 0-9 e _. A função interna, anonymous, se aplica a todos os usuários. A função interna, authenticated, se aplica a todos os usuários que fizeram logon. Os usuários devem pertencer a pelo menos uma função. As funções são comparadas usando o operador OR. Se um usuário estiver em qualquer uma das funções listadas, o acesso será concedido. Os usuários individuais são associados a funções por meio de convites.

Cada propriedade tem uma finalidade específica no pipeline de solicitação/resposta.

Finalidade	Propriedades
Fazer a correspondência de rotas	route, methods
Fazer o processamento depois que uma regra for correspondida e autorizada	rewrite (modifica a solicitação) redirect, headers, statusCode (modifica a resposta)
Dar autorização após a correspondência de uma rota	allowedRoles

Especificar padrões de rota

A propriedade route pode ser uma rota exata ou um padrão curinga.

Rota exata

Para definir uma rota exata, coloque o caminho completo do arquivo na propriedade route.

{
  "route": "/profile/index.html",
  "allowedRoles": ["authenticated"]
}

Essa regra corresponde às solicitações para o arquivo /profile/index.html. Como index.html é o arquivo padrão, a regra também corresponde às solicitações da pasta (/profile ou /profile/).

Padrão de curinga

As regras curinga correspondem a todas as solicitações em um padrão de rota e só têm suporte no final de um caminho. Confira o exemplo de arquivo de configuração para obter exemplos de uso.

Por exemplo, para implementar rotas para um aplicativo de calendário, você pode regenerar todas as URLs que se enquadram na rota calendário para atender a um único arquivo.

{
  "route": "/calendar*",
  "rewrite": "/calendar.html"
}

O arquivo calendar.html pode, então, usar o roteamento do lado do cliente para atender a uma exibição diferente para variações de URL, como /calendar/january/1, /calendar/2020 e /calendar/overview.

Você pode filtrar correspondências curinga por extensão de arquivo. Por exemplo, se você quisesse adicionar uma regra que só corresponde a arquivos HTML em um determinado caminho, você poderia criar a seguinte regra:

{
  "route": "/articles/*.html",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

Para filtrar várias extensões de arquivo, inclua as opções entre chaves, conforme mostrado neste exemplo:

{
  "route": "/images/thumbnails/*.{png,jpg,gif}",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

Os casos de uso comuns de rotas curinga incluem:

• Fornecer um arquivo específico para um padrão de caminho inteiro
• Impor regras de autenticação e autorização
• Implementar regras de cache especializadas

Proteger as rotas com funções

As rotas são protegidas pela adição de um ou mais nomes de função na matriz de allowedRoles de uma regra. Confira o exemplo de arquivo de configuração para obter exemplos de uso.

Por padrão, cada usuário pertence à função anonymous interna e todos os usuários conectados são membros da função authenticated. Opcionalmente, os usuários são associados a funções personalizadas por meio de convites.

Por exemplo, para restringir uma rota somente a usuários autenticados, adicione a função authenticated interna à matriz de allowedRoles.

{
  "route": "/profile*",
  "allowedRoles": ["authenticated"]
}

Você pode criar novas funções conforme necessário na matriz de allowedRoles. Para restringir uma rota a apenas administradores, você pode definir a própria função chamada de administrator, na matriz allowedRoles.

{
  "route": "/admin*",
  "allowedRoles": ["administrator"]
}

• Você tem controle total sobre os nomes de função; não há nenhuma lista à qual suas funções devem se ater.
• Os usuários individuais são associados a funções por meio de convites.

Restringir o acesso a todo o aplicativo

Muitas vezes você quer requerer autenticação para cada rota em seu aplicativo. Para bloquear suas rotas, adicione uma regra que corresponda a todas as rotas e inclua a função interna authenticated na matriz allowedRoles.

A configuração de exemplo a seguir bloqueia o acesso anônimo e redireciona todos os usuários não autenticados para a página de entrada do Microsoft Entra.

{
  "routes": [
    {
      "route": "/*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aad"
    }
  }
}

Rotas de fallback

Aplicativos de página única geralmente dependem do roteamento do lado do cliente. Essas regras de roteamento do lado do cliente atualizam o local da janela do navegador sem fazer solicitações de volta ao servidor. Se você atualizar a página ou acessar diretamente as URLs geradas pelas regras de roteamento do lado do cliente, uma rota de fallback do lado do servidor será necessária para atender à página HTML apropriada. A página de fallback geralmente é designada como index.html para seu aplicativo do lado do cliente.

É possível definir uma regra de fallback adicionando uma seção navigationFallback. O exemplo a seguir retorna /index.html para todas as solicitações de arquivo estático que não correspondem a um arquivo implantado.

{
  "navigationFallback": {
    "rewrite": "/index.html"
  }
}

Você pode controlar quais solicitações retornam o arquivo de fallback por meio da definição de um filtro. No exemplo a seguir, as solicitações para determinadas rotas na pasta /images e todos os arquivos na pasta /css são excluídos do retorno do arquivo de fallback.

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  }
}

Por exemplo, com a estrutura de diretório a seguir, a regra de fallback de navegação acima produzirá os resultados detalhados na tabela a seguir.

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
├── about.html
└── index.html

Solicitações para...	retorna...	com o status...
/about/	O arquivo /index.html.	200
/images/logo.png	O arquivo de imagem.	200
/images/icon.svg	O arquivo /index.html, pois a extensão de arquivo svg não está listada no filtro /images/*.{png,jpg,gif}.	200
/images/unknown.png	Erro de arquivo não encontrado.	404
/css/unknown.css	Erro de arquivo não encontrado.	404
/css/global.css	O arquivo de folha de estilos.	200
/about.html	A página HTML.	200
Qualquer outro caminho fora das pastas /images ou /css que não correspondam ao caminho para um arquivo implantado.	O arquivo /index.html.	200

Cabeçalhos globais

A seção globalHeaders fornece um conjunto de cabeçalhos HTTP aplicado a cada resposta, a menos que seja substituído por uma regra de cabeçalho de rota; caso contrário, a união dos cabeçalhos da rota e globais será retornada.

Confira o exemplo de arquivo de configuração para obter exemplos de uso.

Para remover um cabeçalho, defina o valor dele como uma cadeia de caracteres ("") vazia.

Alguns casos de uso comuns dos cabeçalhos globais incluem:

• Personalizar regras de cache
• Políticas de segurança
• Configurações de codificação
• Configuração de compartilhamento de recursos entre origens (CORS)

O exemplo a seguir implementa uma configuração de CORS personalizada.

{
  "globalHeaders": {
    "Access-Control-Allow-Origin": "https://example.com",
    "Access-Control-Allow-Methods": "POST, GET, OPTIONS"
  }
}

Substituições de resposta

A seção responseOverrides fornece uma oportunidade para definir uma resposta personalizada quando o servidor retornasse, de outra forma, um código de erro. Confira o exemplo de arquivo de configuração para obter exemplos de uso.

Os seguintes códigos HTTP estão disponíveis para substituição:

Código de status	Significado	Causa possível
400	Solicitação incorreta	Link de convite inválido
401	Não Autorizado	Solicitação para páginas restritas enquanto a autenticação não foi realizada
403	Proibido	O usuário fez logon, mas não tem as funções necessárias para exibir a página. O usuário está conectado, mas o runtime não pode obter os detalhes do usuário com base nas declarações de identidade dele. Há muitos usuários que fizeram logon no site com funções personalizadas. Portanto, o runtime não pode conectar o usuário.
404	Não encontrado	Arquivo não encontrado

A configuração de exemplo a seguir demonstra como substituir um código de erro.

{
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "statusCode": 302,
      "redirect": "/login"
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/custom-404.html"
    }
  }
}

Plataforma

A seção platform controla as configurações específicas da plataforma, como a versão de runtime da linguagem de API.

Selecionar a versão de runtime da linguagem de API

Para configurar a versão de runtime da linguagem de API, defina a propriedade apiRuntime na seção platform como um dos valores com suporte a seguir.

Versão de runtime da linguagem	Sistema operacional	Versão do Azure Functions	apiRuntime valor	Data de fim do suporte
.NET Core 3.1	Windows	3.x	dotnet:3.1	3 de dezembro de 2022
.NET 6.0 em processo	Windows	4.x	dotnet:6.0	-
.NET 6.0 isolado	Windows	4.x	dotnet-isolated:6.0	-
.NET 7.0 isolado	Windows	4.x	dotnet-isolated:7.0	-
.NET 8.0 isolado	Windows	4.x	dotnet-isolated:8.0	-
Node.js 12.x	Linux	3.x	node:12	3 de dezembro de 2022
Node.js 14.x	Linux	4.x	node:14	-
Node.js 16.x	Linux	4.x	node:16	-
Node.js 18.x	Linux	4.x	node:18	-
Node.js 20.x (versão prévia)	Linux	4.x	node:20	-
Python 3.8	Linux	4.x	python:3.8	-
Python 3.9	Linux	4.x	python:3.9	-
Python 3.10	Linux	4.x	python:3.10	-

.NET

Para alterar a versão do runtime em um aplicativo .NET, altere o valor de TargetFramework no arquivo csproj. Embora isso seja opcional, se você definir um valor de apiRuntime no arquivo staticwebapp.config.json, verifique se o valor corresponde ao que definido no arquivo csproj.

O exemplo a seguir demonstra como atualizar o elemento TargetFramework para o NET 8.0 como a versão de runtime da linguagem da API no arquivo csproj.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    ...
  </PropertyGroup>
...

Node.js

A configuração de exemplo a seguir demonstra como usar a propriedade apiRuntime para selecionar o Node.js 16 como a versão de runtime da linguagem da API no arquivo staticwebapp.config.json.

{
  ...
  "platform": {
    "apiRuntime": "node:16"
  }
  ...
}

Python

A configuração de exemplo a seguir demonstra como usar a propriedade apiRuntime para selecionar o Python 3.8 como a versão de runtime da linguagem da API no arquivo staticwebapp.config.json.

{
  ...
  "platform": {
    "apiRuntime": "python:3.8"
  }
  ...
}

Rede

A seção networking controla a configuração de rede do aplicativo Web estático. Para restringir o acesso ao aplicativo, especifique uma lista de blocos de endereço IP permitidos em allowedIpRanges. Para obter mais informações sobre o número de blocos de endereços IP permitidos, consulte Cotas em Aplicativos Web Estáticos do Azure.

Defina cada bloco de endereço IPv4 na notação CIDR (Roteamento entre Domínios sem Classificação). Para saber mais sobre a notação CIDR, confira Roteamento entre domínios sem classe. Cada bloco de endereço IPv4 pode indicar um espaço de endereço público ou privado. Se você quiser apenas permitir o acesso de um endereço IP, use o bloco CIDR /32.

{
  "networking": {
    "allowedIpRanges": [
      "10.0.0.0/24",
      "100.0.0.0/32",
      "192.168.100.0/22"
    ]
  }
}

Quando um ou mais blocos de endereço IP são especificados, as solicitações provenientes de endereços IP que não corresponderem a um valor em allowedIpRanges terão o acesso negado.

Além dos blocos de endereços IP, você também pode especificar marcas de serviço na matriz allowedIpRanges para restringir o tráfego a determinados serviços do Azure.

"networking": {
  "allowedIpRanges": ["AzureFrontDoor.Backend"]
}

Autenticação

• Provedores de autenticação padrão não exigem definições no arquivo de configuração.

• Os provedores de autenticação personalizados usam a seção auth do arquivo de configurações.

Para obter detalhes sobre como restringir rotas a usuários autenticados, consulte Proteger rotas com funções.

Desabilitar o cache para caminhos autenticados

Se configurar a integração manual com o Azure Front Door, você talvez queira desabilitar o armazenamento cache para suas rotas protegidas. Com a borda de nível empresarial habilitada, o cache já está desabilitado para suas rotas seguras.

Para desabilitar o cache do Azure Front Door para rotas protegidas, adicione "Cache-Control": "no-store" à definição do cabeçalho de rota.

Por exemplo:

{
    "route": "/members",
    "allowedRoles": ["authenticated, members"],
    "headers": {
        "Cache-Control": "no-store"
    }
}

Gateway de encaminhamento

A seção forwardingGateway configura como um aplicativo web estático é acessado de um gateway de encaminhamento, como uma CDN (Rede de Distribuição de Conteúdo) ou Azure Front Door.

Hosts encaminhados permitidos

A lista allowedForwardedHosts especifica quais nomes de host aceitar no cabeçalho de host X encaminhado. Se um domínio correspondente estiver na lista, os Aplicativos Web Estáticos usarão o valor X-Forwarded-Host ao construir URLs de redirecionamento, como após uma entrada bem-sucedida.

Para que aplicativos Web estáticos funcionem corretamente por trás de um gateway de encaminhamento, a solicitação do gateway deve incluir o nome de host correto no cabeçalho X-Forwarded-Host e o mesmo nome de host deve ser listado emallowedForwardedHosts.

"forwardingGateway": {
  "allowedForwardedHosts": [
    "example.org",
    "www.example.org",
    "staging.example.org"
  ]
}

Se o cabeçalho X-Forwarded-Host não corresponder a um valor na lista, as solicitações ainda serão realizadas, mas o cabeçalho não será usado na resposta.

Cabeçalhos necessários

Os cabeçalhos necessários são cabeçalhos HTTP que devem ser enviados com cada solicitação ao seu site. Um uso dos cabeçalhos necessários é negar o acesso a um site, a menos que todos os cabeçalhos necessários estejam presentes em cada solicitação.

Por exemplo, a configuração a seguir mostra como você pode adicionar um identificador exclusivo para o Azure Front Door que limita o acesso ao seu site de uma instância específica do Azure Front Door. Consulte o Tutorial configurar o Azure Front Door para obter detalhes completos.

"forwardingGateway": {
  "requiredHeaders": {
    "X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
  }
}

• Pares de chave/valor podem ser qualquer conjunto de cadeias de caracteres arbitrárias
• As chaves não diferenciam maiúsculas e minúsculas
• Os valores diferenciam maiúsculas de minúsculas

Barra à direita

Uma barra à direita é o / no final de uma URL. Convencionalmente, uma URL com uma barra à direita refere-se a um diretório no servidor Web, enquanto uma URL sem uma barra à direita indica um arquivo.

Os mecanismos de pesquisa tratam as duas URLs separadamente, sem importar se é um arquivo ou um diretório. Quando o mesmo conteúdo é renderizado em ambas as URLs, o site fornece um conteúdo duplicado, o que pode afetar negativamente a SEO (otimização do mecanismo de pesquisa). Quando configurados explicitamente, os Aplicativos Web Estáticos aplicam um conjunto de regras de normalização e redirecionamento de URL que ajudam a melhorar o desempenho do site e o desempenho de SEO.

As seguintes regras de normalização e redirecionamento se aplicam a cada uma das configurações disponíveis:

Sempre

Quando você define trailingSlash como always, todas as solicitações que não incluem uma barra à direita são redirecionadas para uma URL com barra à direita. Por exemplo, /contact é redirecionado para /contact/.

"trailingSlash": "always"

Solicitações para...	retorna...	com o status...	e caminho...
/about	O arquivo /about/index.html	301	/about/
/about/	O arquivo /about/index.html	200	/about/
/about/index.html	O arquivo /about/index.html	301	/about/
/privacy.html	O arquivo /privacy.html	301	/privacy/

Nunca

Ao definir trailingSlash como never, todas as solicitações que terminam com uma barra à direita são redirecionadas para uma URL sem barra à direita. Por exemplo, /contact/ é redirecionado para /contact.

"trailingSlash": "never"

Solicitações para...	retorna...	com o status...	e caminho...
/about	O arquivo /about/index.html	200	/about
/about/	O arquivo /about/index.html	301	/about
/about/index.html	O arquivo /about/index.html	301	/about
/privacy.html	O arquivo /privacy.html	301	/privacy

Automático

Quando você define trailingSlash como auto, todas as solicitações para pastas são redirecionadas para uma URL com uma barra à direita. Todas as solicitações para arquivos são redirecionadas para uma URL sem barra à direita.

"trailingSlash": "auto"

Solicitações para...	retorna...	com o status...	e caminho...
/about	O arquivo /about/index.html	301	/about/
/about/	O arquivo /about/index.html	200	/about/
/about/index.html	O arquivo /about/index.html	301	/about/
/privacy.html	O arquivo /privacy.html	301	/privacy

Para obter o desempenho ideal do site, configure uma estratégia de barra à direita usando um entre os modos always, never ou auto.

Por padrão, quando a configuração trailingSlash é omitida, os Aplicativos Web Estáticos aplicam as seguintes regras:

Solicitações para...	retorna...	com o status...	e caminho...
/about	O arquivo /about/index.html	200	/about
/about/	O arquivo /about/index.html	200	/about/
/about/index.html	O arquivo /about/index.html	200	/about/index.html
/privacy.html	O arquivo /privacy.html	200	/privacy.html

Exemplo de arquivo de configuração

{
  "trailingSlash": "auto",
  "routes": [
    {
      "route": "/profile*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/admin/index.html",
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/images/*",
      "headers": {
        "cache-control": "must-revalidate, max-age=15770000"
      }
    },
    {
      "route": "/api/*",
      "methods": ["GET"],
      "allowedRoles": ["registeredusers"]
    },
    {
      "route": "/api/*",
      "methods": ["PUT", "POST", "PATCH", "DELETE"],
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/api/*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/customers/contoso*",
      "allowedRoles": ["administrator", "customers_contoso"]
    },
    {
      "route": "/login",
      "rewrite": "/.auth/login/github"
    },
    {
      "route": "/.auth/login/x",
      "statusCode": 404
    },
    {
      "route": "/logout",
      "redirect": "/.auth/logout"
    },
    {
      "route": "/calendar*",
      "rewrite": "/calendar.html"
    },
    {
      "route": "/specials",
      "redirect": "/deals",
      "statusCode": 301
    }
  ],
  "navigationFallback": {
    "rewrite": "index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  },
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "redirect": "/login",
      "statusCode": 302
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/404.html"
    }
  },
  "globalHeaders": {
    "content-security-policy": "default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'"
  },
  "mimeTypes": {
    ".json": "text/json"
  }
}

Com base na configuração acima, examine os cenários a seguir.

Solicitações para...	resulta em...
/profile	Os usuários autenticados recebem o arquivo /profile/index.html. Usuários não autenticados são redirecionados para /login pela regra de substituição de resposta 401.
/admin, /admin/ ou /admin/index.html	Os usuários autenticados na função administrator recebem o arquivo /admin/index.html. Os usuários autenticados que não estão na função administrator recebem um erro 4031. Usuários não autenticados são redirecionados para /login
/images/logo.png	Fornece a imagem com uma regra de cache personalizada em que a idade máxima é um pouco maior que 182 dias (15.770.000 segundos).
/api/admin	As solicitações GET de usuários autenticados na função registeredusers são enviadas para a API. Os usuários autenticados que não estão na função registeredusers e usuários não autenticados recebem um erro 401. As solicitações POST, PUT, PATCH e DELETE de usuários autenticados na função administrator são enviadas para a API. Os usuários autenticados que não estão na função administrator e usuários não autenticados recebem um erro 401.
/customers/contoso	Usuários autenticados que pertencem à função administrator ou customers_contoso recebem o arquivo /customers/contoso/index.html. Usuários autenticados que não estão na função administrator ou customers_contoso recebem um erro 4031. Usuários não autenticados são redirecionados para /login.
/login	Os usuários não autenticados são desafiados a autenticar com o GitHub.
_/.auth/login/x	Como a regra de rota desabilita a autorização do X, será retornado um erro 404. Em seguida, esse erro fará um fallback para distribuir /index.html com um código de status 200.
/logout	Os usuários são desconectados de qualquer provedor de autenticação.
/calendar/2021/01	O navegador recebe o arquivo /calendar.html.
/specials	O navegador é redirecionado permanentemente para /deals.
/data.json	O arquivo fornecido com o tipo MIME text/json.
/about ou qualquer pasta que corresponda aos padrões de roteamento do lado do cliente	O arquivo /index.html é fornecido com um código de status 200.
Um arquivo não existente na pasta /images/	Um erro 404.

¹ Você pode fornecer uma página de erro personalizada usando uma regra de substituição de resposta.

Restrições

As restrições a seguir existem para o arquivo staticwebapps.config.json.

• O tamanho máximo do arquivo é de 20 KB
• Máximo de 50 funções diferentes

Confira o artigo Cotas para ver as restrições gerais e limitações.

Próximas etapas

Artigos relacionados

• Definir as configurações de nível de aplicativo e as variáveis de ambiente usadas pelas APIs de back-end
• Definir as configurações que controlam o processo build