Александр Воробьев#: В общем случае да, но тут речь об очень конкретном случае. И только.
Я об этом и писал. Если у вас в шаблоне маршрута не описана строка запроса (хотя маршрутизатор позволяет), то соответственно запросы по адресам с вопросительным знаком на конце будут приводить к вызову обработчика ошибки, который выдает 404 и т.п. Например, посмотрите сайт у меня в подписи. Там используется каркас, не порождающий дубли. На уровень Web-сервера вынесена только обработка трэйлинг-слэшей. Все остальное внутри каркаса, в частности завершающий вопросительный знак будет "отброшен" при помощи общего шаблона адреса. Его окончание:
(\\?p=[1-9]\\d{0,9})?$#
Т.е. либо строка запроса по формату, либо никакой, включая разделитель вопросительный знак.
Александр Воробьев#: Изначально вопрос был именно о более конкретном случае: когда после "?" вообще ни чего нет. И тут суть в том, что это общее правило, на мой взгляд, для подавляющего большинства сайтов.
Да, адреса с вопросительным знаком на конце используются редко для какой-то другой функциональности, чем 404/301.
Александр Воробьев#: По этому я и размышлял единожды засунуть редирект в настройки nginx
Если у вас шаблоны адресов в маршрутах описывают в том числе и строку запроса (query string) или ее отсутствие, то специально что-то общее можно не писать. Общая проверка на ранних этапах обработки запроса может быть даже хуже, чем частные или более комплексные общие на поздних. Даже несмотря на то, что в последнем случае нужно еще передавать управление php, etc.
Dmitriy_2014 : Такое ощущение что сейчас тег hr(линия), никто и нигде не использует, понятное дело в дизайне и стилях его точно не применяют
hr - это "средство выразительности" при форматировании текста. Дизайнеры тоже могут касаться применения этого тега, если они следят за тем, что творят создатели основного содержимого.
А сроки давности здесь какие-то есть (смерть автора не беру в расчет)? А то недавно "прилетело" за фото (тоже миниатюру), которое на стоке покупал подрядчик больше 10 лет назад. Организация с ним давно не работает. Лицензия (справка) давно утрачена, как и аккаунт на этом стоке. И тут контент-менеджер выбирает это фото из давно загруженной коллекции... 😊
Sly32#: Потому что вопрос неконкретный. Если перекидывать файлы/картинки для контекста это одно. Код - другое.
Но ты же понимаешь, что почти все пользователи этого форума не держат репозитории своих сайтов даже на локалке. Самый распространенный способ развертывания кода - "закинуть" архив дистрибутива на сервер и там распаковать, установить/настроить, либо скопировать распакованный дистрибутив. То же самое касается "контента", когда идет речь о технологических операциях: копируют архивы с дампами баз данных и каталогами файлов данных. С отдельными элементами кода и данных могут поступать аналогично. Хотя контент обычно загружают через админку. И даже программные модули могут скачать/установить через админку.
Кстати, если на то пошло, можно и отдельные файлы данных загружать при помощи VCS. С клиентским кэшированием одноименных файлов бороться точно так же, как и с кэшированием JS/CSS-кода. Хотя с индексированием будет сложно. Тоже понадобятся комплексные операции.
Я нет. Автор темы спрашивал "что-то модное, современное, молодежное для передачи файлов от компа к серверу и обратно". Мы здесь в основном для него "накидываем варианты". Я увидел только "какой-то API", VCS (Git). И потом еще кучу "бесполезного трепа", в котором сам с удовольствием поучаствовал 😊
Mik Foxi#: или залить исправленный 1 php файл с микро правкой
"Микроправки" тоже можно "коммитить". Соответственно они могут порождать новые версии "продукта". Тем более что вы их "выкатываете" на "прод".
В редких случаях "микроправки" могут приводить к плохим последствиям, которые не сразу удается распознать. В системах контроля версий проще сделать автоматизированный откат, чем "микроправку назад".
С другой стороны я вас хорошо понимаю. Вполне можно результат "микроправок" не считать новой версией, даже "внутренней" (технологической). Но в принципе увеличить какой-нибудь "четвертый октет" в номере версии не трудно.
В общем случае да, но тут речь об очень конкретном случае. И только.
Я об этом и писал. Если у вас в шаблоне маршрута не описана строка запроса (хотя маршрутизатор позволяет), то соответственно запросы по адресам с вопросительным знаком на конце будут приводить к вызову обработчика ошибки, который выдает 404 и т.п. Например, посмотрите сайт у меня в подписи. Там используется каркас, не порождающий дубли. На уровень Web-сервера вынесена только обработка трэйлинг-слэшей. Все остальное внутри каркаса, в частности завершающий вопросительный знак будет "отброшен" при помощи общего шаблона адреса. Его окончание:
Т.е. либо строка запроса по формату, либо никакой, включая разделитель вопросительный знак.
Изначально вопрос был именно о более конкретном случае: когда после "?" вообще ни чего нет. И тут суть в том, что это общее правило, на мой взгляд, для подавляющего большинства сайтов.
Да, адреса с вопросительным знаком на конце используются редко для какой-то другой функциональности, чем 404/301.
По этому я и размышлял единожды засунуть редирект в настройки nginx
Если у вас шаблоны адресов в маршрутах описывают в том числе и строку запроса (query string) или ее отсутствие, то специально что-то общее можно не писать. Общая проверка на ранних этапах обработки запроса может быть даже хуже, чем частные или более комплексные общие на поздних. Даже несмотря на то, что в последнем случае нужно еще передавать управление php, etc.
Такое ощущение что сейчас тег hr(линия), никто и нигде не использует, понятное дело в дизайне и стилях его точно не применяют
О! Спасиб. 170 рубасов продление.
Непосредственно в Axelname столько же при наличии 10 доменов.
- .pro увести в Ардис по 1799 рублей продление
Потому что вопрос неконкретный. Если перекидывать файлы/картинки для контекста это одно. Код - другое.
Но ты же понимаешь, что почти все пользователи этого форума не держат репозитории своих сайтов даже на локалке. Самый распространенный способ развертывания кода - "закинуть" архив дистрибутива на сервер и там распаковать, установить/настроить, либо скопировать распакованный дистрибутив. То же самое касается "контента", когда идет речь о технологических операциях: копируют архивы с дампами баз данных и каталогами файлов данных. С отдельными элементами кода и данных могут поступать аналогично. Хотя контент обычно загружают через админку. И даже программные модули могут скачать/установить через админку.
Кстати, если на то пошло, можно и отдельные файлы данных загружать при помощи VCS. С клиентским кэшированием одноименных файлов бороться точно так же, как и с кэшированием JS/CSS-кода. Хотя с индексированием будет сложно. Тоже понадобятся комплексные операции.
Нет, но ты разве спрашивал?
Вроде нет, не писал)
Значит, скрыл основное 😀 Вот как после этого тебе верить? 😂
А в каком случае - неэффективный?
Я пытался описать один вариант.
четвертый???
Да хоть пятый. Я разное повидал за свою деятельность "не разработчика" 😊
или залить исправленный 1 php файл с микро правкой
"Микроправки" тоже можно "коммитить". Соответственно они могут порождать новые версии "продукта". Тем более что вы их "выкатываете" на "прод".
В редких случаях "микроправки" могут приводить к плохим последствиям, которые не сразу удается распознать. В системах контроля версий проще сделать автоматизированный откат, чем "микроправку назад".
С другой стороны я вас хорошо понимаю. Вполне можно результат "микроправок" не считать новой версией, даже "внутренней" (технологической). Но в принципе увеличить какой-нибудь "четвертый октет" в номере версии не трудно.
Ни в одном из них нет SFTP))) Мне мое время дорого.