Были описаны два способа (хотя формально делегированием называется способ, использующий NS-записи). Какой не работает? Делегирование может занимать до нескольких суток. Активизация A-записи тоже может происходить не мгновенно.
У многих провайдеров при добавлении домена 3-го уровня и сайта на таком домене нужно сначала добавить соответствующий домен 2-го уровня. Ничего что этот домен 2-го уровня и сайт на нем размещены на другом (DNS-)хостинге.
Не забудьте, что при делегировании нужно указывать минимум две записи с разными значениями (именами DNS-серверов), например:
webinfo#: Ибо эта фраза не несёт смысловой нагрузки
Выше уточнил. Смысл был в том, что общий обработчик может быть связан с GET чисто формально по имени, а не быть каким-нибудь специальным default, special, etc.
Во-вторых, попробуй придумать причину, по которой я не могу использовать для удаления объекта GET-запрос.
А зачем что-то придумывать, когда можно просто прочитать документацию и т.п.? 😊
У меня, например, разговор короткий с теми, кто делает так:
GET /collection?action=create&id=object
GET /collection?action=delete&id=object
Даже если речь об "адаптиве" под GET/POST, упомянутые действия нужно выполнять методом POST.
Я ответил?
Если IP, то 1
Я же сразу написал, о каких значениях идет речь (именах DNS-серверов)! И выше уточнил, что такое делегирование.
описанный способ не работает
Были описаны два способа (хотя формально делегированием называется способ, использующий NS-записи). Какой не работает? Делегирование может занимать до нескольких суток. Активизация A-записи тоже может происходить не мгновенно.
У многих провайдеров при добавлении домена 3-го уровня и сайта на таком домене нужно сначала добавить соответствующий домен 2-го уровня. Ничего что этот домен 2-го уровня и сайт на нем размещены на другом (DNS-)хостинге.
Не забудьте, что при делегировании нужно указывать минимум две записи с разными значениями (именами DNS-серверов), например:
subdomain NS ns1.estic.ru. 21600
subdomain NS ns2.estic.ru. 21600
(21600 - это пример значения TTL, если нужно).
Смотря по тому, какова цель.
В маршрутизаторе может вызываться и сущность более высокого уровня - например, файл.
Может. Тогда это тоже обработчик.
В любом случае, обработчик привязывается к цели обработки. Метод запроса - вторичный параметр.
Т.е. достигнуть "цель обработки" можно при помощи любого метода запроса? Можно выбрать любой метод?
Что Вы называете обработчиком?
Метод класса, обычная или анонимная функция и т.д. Т.е. то что вызывается в маршрутизаторе при маршрутизации, но не относится непосредственно к нему.
С нашей точки зрения, действия вешаются на данные, поступившие с запросом.
Правильно ли я понял, что с вашей точки зрения можно любые действия "повесить" на GET?
Обработчик вешается на конкретный запрос.
В смысле один обработчик на один адрес (адреса одного формата)? И не более одного?
Вообще говоря, едва ли кому-то придёт в голову делать разные обработчики для разных методов запросов.
Вы серьезно? Это распространенная практика. Для приверженцев REST - вовсе "норма жизни".
Обработчик делается исходя из целей обработки, а не исходя из метода запроса.
Т.е. любой обработчик можно "повесить" на любой метод и будет нормально? 😊
Ибо эта фраза не несёт смысловой нагрузки
Выше уточнил. Смысл был в том, что общий обработчик может быть связан с GET чисто формально по имени, а не быть каким-нибудь специальным default, special, etc.