Http error 1: angularjs — Angular HTTP: Status -1 and CORS — Эксперт — интернет-магазин электроники и бытовой техники

Содержание

Страница недоступна, пока не может обработать этот запрос – Вопросы Timeweb Community

Ибрагимов Тимур Шафаилович

28 июля в 2017

7205

1 ответ

1) Установил OPENCART по инструкции

2) админ панель работает

3) А когда захожу на сайт пишет

Страница недоступна

Сайт leonhotel.ru пока не может обработать этот запрос.

HTTP ERROR 500

В логе нашел

leonhotel.ru [Fri Jul 28 09:50:42 2017] [error] [pid 19395] sapi_apache2.c(325): [client 92.53.115.234:34514] PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback, first array member is not a valid class name or object in /home/c/cg09891/leonhotel.ru/public_html/system/engine/action.php on line 51
leonhotel.ru [Fri Jul 28 09:50:52 2017] [error] [pid 19898] sapi_apache2.c(325): [client 92.53. 115.234:39460] PHP Fatal error: Class 'Controllereventcompatibility' not found in /home/c/cg09891/leonhotel.ru/public_html/system/engine/action.php on line 43

ПОМОГИТЕ

OpenCart

Установка opencart на хостинг

Я установил версию opencart через timeweb а она там далеко не последняя. Смотрю гайды и у в 3.0.8.0 если не ошибаюсь дизайн гораздо ингтереснее ,выпадающие меню,красивые кнопки. Вобщем я решил удалить сайт подчистую все удалил через ftp осталась только…

Другое

1 ответ

milan

02 марта в 2022

1. 3K

Взял заказ на фрилансе CMS Opencart

Здравствуйте. Я взял первый свой заказ на фрилансе, но не знаю как зайти в админку opencart. Помогите пожалуйста.

Разработка

5 ответов

Усов Дмитрий Валентинович 30 июля в 2021

1.2K

htacсess не хочет переадресовывать урлы с index.php/

Здравствуйте ! Перевожу старый сайт со сторонней cms на новый сайт — движок opencart Делаю переадресацию в .htacess Иногда нужно переадресовывать подобные урлы index.php/cat/c706_Derevo-schastya.html Делаю таким образом — не срабатывает RewriteCond.

Другое

1 ответ

Как работать с ошибками бизнес-логики через HTTP / Хабр

Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры «дергают» бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.

За 7 лет я как поддерживал множество legacy API, так и разрабатывал c нуля. И я поработал, наверное, с большинством стратегий по возвращению ошибок, но каждая из них создавала дискомфорт в той или иной мере. В последнее время я нащупал оптимальный вариант, о котором и хочу рассказать, но с начала расскажу о двух наиболее популярных вариантах.

Если почитать апологетов REST, то для кодов ошибок надо использовать HTTP статусы, а текст ошибки отдавать в теле или в специальном заголовке. Например:

Success:

HTTP 200 GET /v1/user/1
Body: { name: 'Вася' }

Error:

HTTP 404 GET /v1/user/1
Body: 'Не найден пользователь'

Если у вас примитивная бизнес-логика или API из 5 url, то в принципе это нормальный подход. Однако как-только бизнес-логика станет сложнее, то начнется ряд проблем.

Http статусы предназначались для описания ошибок при передаче данных, а про логику вашего приложения никто не думал. Статусов явно не хватает для описания всего разнообразия ошибок в вашем проекте, да они и не были для этого предназначены. И тут начинается натягивание «совы на глобус»: все начинают спорить, какой статус ошибки дать в том или ином случае. Пример: Есть API для task manager. Какой статус надо вернуть в случае, если пользователь хочет взять задачу, а ее уже взял в работу другой пользователь? Ссылка на http статусы. И таких проблемных примеров можно придумать много.

REST скорее концепция, чем формат общения из чего следует неоднозначность использования статусов. Разработчики используют статусы как им заблагорассудится. Например, некоторые API при отсутствии сущности возвращают 404 и текст ошибки, а некоторые 200 и пустое тело.

Бэкенд разработчику в проекте непросто выбрать статус для ошибки, а клиентскому разработчику неочевидно какой статус предназначен для того или иного типа ошибок бизнес-логики. По-хорошему в проекте придется держать enum для того, чтобы описать какие ошибки относятся к тому или иному статусу.

Когда бизнес-логика приложения усложняется, начинают делать как-то так:

HTTP 400 PUT /v1/task/1 { status: 'doing' }
Body: { error_code: '12', error_message: 'Задача уже взята другим исполнителем' }

Из-за ограниченности http статусов разработчики начинают вводить “свои” коды ошибок для каждого статуса и передавать их в теле ответа. Другими словами, пользователю API приходится писать нечто подобное:

if (status === 200) {
  // Success
} else if (status === 500) {
  // some code
} else if (status === 400) {
  if (body.error_code === 1) {
    // some code
  } else if (body.error_code === 2) {
    // some code
  } else {
    // some code
  }
} else if (status === 404) {
  // some code
} else {
  // some code
}

Из-за этого ветвление клиентского кода начинает стремительно расти: множество http статусов и множество кодов в самом сообщении. Для каждого ошибочного http статуса необходимо проверить наличие кодов ошибок в теле сообщения. От комбинаторного взрыва начинает конкретно пухнуть башка! А значит обработку ошибок скорее всего сведут к сообщению типа “Произошла ошибка” или к молчаливому некорректному поведению.

Многие системы мониторинга сервисов привязываются к http статусам, но это не помогает в мониторинге, если статусы используются для описания ошибок бизнес логики. Например, у нас резкий всплеск ошибок 429 на графике.

Это началась DDOS атака, или кто-то из разработчиков выбрал неудачный статус?

Итог: Начать с таким подходом легко и просто и для простого API это вполне подойдет. Но если логика стала сложнее, то использование статусов для описания того, что не укладывается в заданные рамки протокола http приводит к неоднозначности использования и последующим костылям для работы с ошибками. Или что еще хуже к формализму, что ведет к неприятному пользовательскому опыту.

№2: На все 200

Есть другой подход, даже более старый, чем REST, а именно: на все ошибки связанные с бизнес-логикой возвращать 200, а уже в теле ответа есть информация об ошибке. Например:

Вариант 1:

Success:
HTTP 200 GET /v1/user/1
Body: { ok: true, data: { name: 'Вася' } }
Error:
HTTP 200 GET /v1/user/1
Body: { ok: false, error: { code: 1, msg: 'Не найден пользователь' } }

Вариант 2:

Success:
HTTP 200 GET /v1/user/1
Body: { data: { name: 'Вася' }, error: null }
Error:
HTTP 200 GET /v1/user/1
Body: { data: null, error: { code: 1, msg: 'Не найден пользователь' } }

На самом деле формат зависит от вас или от выбранной библиотеки для реализации коммуникации, например JSON-API.

Звучит здорово, мы теперь отвязались от http статусов и можем спокойно ввести свои коды ошибок. У нас больше нет проблемы “впихнуть невпихуемое”. Выбор нового типа ошибки не вызывает споров, а сводится просто к введению нового числового номера (например, последовательно) или строковой константы. Например:

module.exports = {
  NOT_FOUND: 1,
  VALIDATION: 2,
 // ….
}
module.exports = {
  NOT_FOUND: ‘NOT_AUTHORIZED’,
  VALIDATION: ‘VALIDATION’,
 // ….
}

Клиентские разработчики просто основываясь на кодах ошибок могут создать классы/типы ошибок и притом не бояться, что сервер вернет один и тот же код для разных типов ошибок (из-за бедности http статусов).

Обработка ошибок становится менее ветвящейся, множество http статусов превратились в два: 200 и все остальные (ошибки транспорта).

if (status === 200) {
  if (body.error) {
    var error = body.error;
    if (error.code === 1) {
      // some code
    } else if (error.code === 2) {
      // some code
    } else {
      // some code
    }
  } else {
    // Success
  }
} else {
  // transport erros
}

В некоторых случаях, если есть библиотека десериализации данных, она может взять часть работы на себя. Писать SDK вокруг такого подхода проще нежели вокруг той или иной имплементации REST, ведь реализация зависит от того, как это видел автор. Кроме того, теперь никто не вызовет случайное срабатывание alert в мониторинге из-за того, что выбрал неудачный код ошибки.

Но неудобства тоже есть:

Избыточность полей при передаче данных, т.е. нужно всегда передавать 2 поля: для данных и для ошибки. Это усложняет чтение логов и написание документации.
При использовании средств отладки (Chrome DevTools) или других подобных инструментов вы не сможете быстро найти ошибочные запросы бизнес логики, придется обязательно заглянуть в тело ответа (ведь всегда 200)
Мониторинг теперь точно будет срабатывать только на ошибки транспорта, а не бизнес-логики, но для мониторинга логики надо будет дописывать парсинг тела сообщения.

В некоторых случаях данный подход вырождается в RPC, то есть по сути вообще отказываются от использования url и шлют все на один url методом POST, а в теле сообщения передают все параметры. Мне кажется это не правильным, ведь url это прекрасный именованный namespace, зачем от этого отказываться, не понятно?! Кроме того, RPC создает проблемы:

нельзя кэшировать по http GET запросы, так как замешали чтение и запись в один метод POST
нельзя делать повторы для неудавшихся GET запросов (на backend) на реверс-прокси (например, nginx) по указанной выше причине
имеются проблемы с документированием – swagger и ApiDoc не подходят, а удобных аналогов я не нашел

Итог: Для сложной бизнес-логики с большим количеством типов ошибок такой подход лучше, чем расплывчатый REST, не зря в проектах c “разухабистой” бизнес-логикой часто именно такой подход и используют.

№3: Смешанный

Возьмем лучшее от двух миров. Мы выберем один http статус, например, 400 или 422 для всех ошибок бизнес-логики, а в теле ответа будем указывать код ошибки или строковую константу. Например:

Success:

HTTP 200 /v1/user/1
Body: { name: 'Вася' }

Error:

HTTP 400 /v1/user/1
Body: { error: { code: 1, msg: 'Не найден пользователь' } }

Коды:

Тело ответа для удачного запроса у нас имеет произвольную структуру, а вот для ошибки есть четкая схема. Мы избавляемся от избыточности данных (поле ошибки/данных) благодаря использованию http статуса в сравнении со вторым вариантом. Клиентский код упрощается в плане обработки ошибки (в сравнении с первым вариантом). Также мы снижаем его вложенность за счет использования отдельного http статуса для ошибок бизнес логики (в сравнении со вторым вариантом).

if (status === 200) {
  // Success
} else if (status === 400) {
  if (body.error.code === 1) {
    // some code
  } else if (body.error.code === 2) {
    // some code
  } else {
    // some code
  }
} else {
  // transport erros
}

Мы можем расширять объект ошибки для детализации проблемы, если хотим. С мониторингом все как во втором варианте, дописывать парсинг придется, но и риска “стрельбы” некорректными alert нету. Для документирования можем спокойно использовать Swagger и ApiDoc. При этом сохраняется удобство использования инструментов разработчика, таких как Chrome DevTools, Postman, Talend API.

Итог: Использую данный подход уже в нескольких проектах, где множество типов ошибок и все крайне довольны, как клиентские разработчики, так и бэкендеры. Внедрение новой ошибки не вызывает споров, проблем и противоречий. Данный подход объединяет преимущества первого и второго варианта, при этом код более читабельный и структурированный.

Самое главное какой бы формат ошибок вы бы не выбрали лучше обговорить его заранее и следовать ему. Если эту вещь пустить на “самотек”, то очень скоро обработка ошибок в проекте станет невыносимо сложной для всех.

P.S. Иногда ошибки любят передавать массивом

{ error: [{ code: 1, msg: 'Не найден пользователь' }] }

Но это актуально в основном в двух случаях:

Когда наш API выступает в роли сервиса без фронтенда (нет сайта/приложения). Например, сервис платежей.
Когда в API есть url для загрузки какого-нибудь длинного отчета в котором может быть ошибка в каждой строке/колонке. И тогда для пользователя удобнее, чтобы ошибки в приложении сразу показывались все, а не по одной.

В противном случае нет особого смысла закладываться сразу на массив ошибок, потому что базовая валидация данных должна происходить на клиенте, зато код упрощается как на сервере, так и на клиенте. А user-experience хакеров, лезущих напрямую в наше API, не должен нас волновать?HTTP

код состояния HTTP -1 означает? — Помощь!

аналогичный 25 ноября 2021 г., 9:23

Я использую openshift, который содержит Haproxy2.0 в качестве маршрута LB, недавно я получил несколько 502 от внешнего интерфейса nginx. Когда я копался в журнале Haproxy, я нашел:
worker-0 haproxy[355]:
. . . :54628 [23/ноября/2021:07:14:34.892] public be_http:des:gateway-esb-http-route/pod:gateway-esb-http-647c66b9cf-5md4w:шлюз-esb-http-сервер:: . . . :8081 0/0/0/-1/0 -1 0 — — SDVN 13/3/1/0/0 0/0 «POST /esb/api HTTP/1.0»

по деликатным причинам я скрыл ИП информация. Мой вопрос: что означает код состояния HTTP «-1»? Я не нашел никакой полезной информации на http://www. haproxy.org/download/2.0/doc/configuration.txt. Из журнала единственное, что я могу получить, это то, что сервер закрыл соединение, но как?

рад 30 ноября 2021 г., 7:47

Привет,

Я предполагаю, что вы используете формат журнала HTTP по умолчанию. Важная информация — таймеры. Вы можете видеть, что TR («0/0/0/-1/0») равен -1. Документ ясен с этим:

«TR» — это общее время в миллисекундах, потраченное на ожидание полного HTTP-запроса от клиента (не считая тела) после получения первого байта. Может быть «-1», если соединение было прервано до того, как можно было получить полный запрос, или был получен неверный запрос. Он всегда должен быть очень маленьким, потому что запрос обычно помещается в один пакет. Большое время здесь обычно указывает на сетевые проблемы между клиентом и haproxy или запросы, вводимые вручную. См. раздел 8.4 «Временные события» для более подробной информации.

Так что это похоже на неполный или неверный запрос.

аналогичный 30 ноября 2021 г., 14:01

Из статуса TR это означает, что соединение было прервано до того, как можно было получить полный запрос или был получен неверный запрос, но код завершения SDVN означает
«Соединение с сервером прервано из-за ошибки во время передачи данных
. Обычно это означает, что haproxy получил RST от
сервер или сообщение ICMP от промежуточного оборудования во время
обмена данными с сервером. Это может быть вызвано сбоем сервера
или проблемой сети на промежуточном оборудовании».
Так что же на самом деле означает журнал? Он закрыт сервером или это был неверный запрос от внешнего интерфейса?

аналогичный 19 мая 2022 г. , 00:31

Оказывается, дело было в дублировании TCP SYN на бэкенд-сервере, с Haproxy все в порядке.

apex — что означает ответ HTTP с кодом состояния -1?

спросил 10 лет, 2 месяца назад

Изменено 10 лет, 2 месяца назад

Просмотрено 12 тысяч раз

Я делаю веб-вызов в классе Batch Apex и иногда получаю HTTPResponse с StatusCode = -1 и Status = null. Любые идеи о том, что это означает?

Ниже приведены записи из журнала отладки:

 15:31:12.416 (5416593000)|CALLOUT_REQUEST|[10]|System.HttpRequest[Endpoint=https://sample.com/changed, Method=PUT]
15:31:12.574 (5574563000)|CALLOUT_RESPONSE|[10]|System.HttpResponse[Status=null, StatusCode=-1]

Редактировать: Обратите внимание, что я спрашиваю о том, почему это происходит на платформе Force. com, а не о том, почему это происходит на Java.

вершина
партия
выноска

-1 не является допустимым кодом ответа HTTP в соответствии со спецификацией, поэтому маловероятно, что сервер предоставляет этот ответ на ваш запрос.

За прошедшие годы на различных сайтах поддержки java появилось несколько тем (а платформа Force.com построена на java), но убедительных ответов не было. Преобладающая теория состоит в том, что статус устанавливается в нуль, а код состояния устанавливается в -1, когда объект ответа создается, а затем что-то происходит с соединением, что означает, что запрос не завершается, поэтому эти значения по умолчанию никогда не перезаписываются реальными значениями.

На что не был получен удовлетворительный ответ ни в одной из этих тем, так это то, как соединение может испортиться без создания исключения.

Если в журналах сервера конечной точки нет ничего, указывающего на проблему, похоже, вам нужно повторить запрос, если вы видите этот статус.

Http error 1: angularjs — Angular HTTP: Status -1 and CORS

Страница недоступна, пока не может обработать этот запрос – Вопросы Timeweb Community

Похожие вопросы

Установка opencart на хостинг

Взял заказ на фрилансе CMS Opencart

htacсess не хочет переадресовывать урлы с index.php/

Как работать с ошибками бизнес-логики через HTTP / Хабр

№2: На все 200

№3: Смешанный

код состояния HTTP -1 означает? — Помощь!

apex — что означает ответ HTTP с кодом состояния -1?

Добавить комментарий Отменить ответ