Удаление. html из всех имен файлов URL с использованием app.yaml для go времени выполнения - PullRequest
Новая
       78

Удаление. html из всех имен файлов URL с использованием app.yaml для go времени выполнения

0 голосов
/ 29 февраля 2020

Я пытаюсь найти руководство или некоторую справку о том, как удалить. html из всех имен файлов url, используя app.yaml для go среды выполнения на движке приложений Google. Я нахожу информацию в справочных документах Google о том, как использовать app.yaml, довольно запутанной, если честно.

У меня около 350. html файлов в 4 папках. Мой файл app.yaml находится в root.

Если это был файл .htaccess, я пытаюсь сделать что-то похожее на приведенное ниже. Есть идеи или советы? 

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^\.]+)$ $1.html [NC,L]

Если бы мне пришлось еще больше сжимать вопрос, я бы хотел также настроить его, чтобы при использовании сервера разработки Webpack и сборки я также мог иметь постоянное использование / опыт (т.е. работать без . html заканчивается на URL), но это может подтолкнуть вопрос на данный момент, и если честно, я не исследовал этот вопрос в данный момент.

1 Ответ

0 голосов
/ 01 марта 2020

Технически, по крайней мере в GAE, вы не удаляете суффикс .html, а скорее добавляете его к запрошенному пути, чтобы получить имя состояния c актив для обслуживания (я предполагаю, что у вас есть файлы с активами .html в их имени).

Это может быть возможно, в зависимости от того, как вы структурируете пространство имен для ваших активов c. ,

Если подмножество (или все) из ваших .html файлов может соответствовать одному шаблону регулярных выражений в пути / имени файла (кроме суффикса .html), который не соответствует другим состояниям c активов, тогда это просто, вам просто нужно 2 оператора обработки. Предполагая, что ниже файлы stati c находятся в каталоге static вашего приложения, настройте его при необходимости.

Первый оператор обработчика будет обслуживать запросы с суффиксом .html, чтобы предотвратить получение 404 для их (в противном случае они будут переведены в нечто вроде /path/file.html.html, что, вероятно, не так, как вы назвали свои активы) 

- url: /(<your_pattern>\.html)$
  static_files: static/\1
  upload: static/<your_pattern>\.html$

2-й оператор будет "добавление" суффикса .html к запрошенный путь и обслуживание соответствующего файла активов (если он существует, или 404, если нет): 

- url: /(<your_pattern>)$
  static_files: static/\1.html
  upload: static/<your_pattern>\.html$

Фактический пример, скажем, ваши файлы .html будут запрошены как /some/path/<file>.html, а вы ' Мне бы хотелось, чтобы они также были доступны как /some/path/<file>. Тогда у вас будут эти операторы-обработчики: 

# this serves your static/some/path/<file>.html asset as /some/path/<file>.html
- url: /(some/path/.*\.html)$
  static_files: static/\1
  upload: static/some/path/.*\.html$

# this serves your static/some/path/<file>.html asset as /some/path/<file>
- url: /(some/path/.*)$
  static_files: static/\1.html
  upload: static/some/path/.*\.html$

Если у вас есть несколько таких подмножеств, вы просто добавите 2 похожих оператора для каждого из них. Но это не масштабируется, если у вас много таких подмножеств.

Если у вас нет такого шаблона (или если у вас слишком много подмножеств), это может быть более трудным. Одна пара операторов со вторым, имеющим шаблон обработчика вслепую / catch-all, все равно будет работать для файлов * stati c .html: 

- url: /(.*\.html)$
  static_files: static/\1
  upload: static/.*\.html$

# catch-all pattern
- url: /(.*)$
  static_files: static/\1.html
  upload: static/.*\.html$

Но это, вероятно, может помешать любым другим stati c файлов и с обработчиками динамического c вашего приложения (если есть). Чтобы избежать этого, вам потребуется всех из них, чтобы их можно было идентифицировать по более конкретным c шаблонам, и вам нужно было бы поместить оператор (ы) для них на выше подвох все один.

...