Ошибка отправки данных проверьте корректность загружаемых данных

• Главная
• Народный top. Рейтинг страховых компаний
• ИНГОССТРАХ
• Отзыв
  #70397

Отзывы о страховой компании «Ингосстрах»

Написать отзыв

Добрый день, не могу продлить полис ОСАГО ХХХ 0119271191 выдает ошибкуORA-20777
«Не удалось загрузить данные в РСА:
ORA-20777: При указании данных по ТС допущена ошибка. Проверьте корректность ввода типа документа на ТС (формат серии ПТС не допускает 4х цифр) или скорректируйте данные в поле „Серия“ (»6355″ документа на ТС. Затем повторите операцию отправки договора/аддендума в РСА.»
Ничего из документов не менялось, но даже если пробую менять — не дает

Уважаемая Елена!

Оформление электронных полисов на сайте Компании осуществляется в штатном режиме.
Отмечаем, что при оформлении полисов ОСАГО требуется взаимодействие со сторонними базами данных: АИС РСА (получение сведений о КБМ), ЕАИСТО (получение сведений о прохождении технического осмотра ТС).
В отдельных случаях единичные проблемы решаются обновлением браузера, очисткой кэша, сменой устройства и/или точки подключения в сети Интернет.
Счет на оплату страховой премии по договору ОСАГО отправлен на Ваш электронный адрес.
После поступления от Вас денежных средств, полис будет направлен на Вашу электронную почту.

С уважением,
СПАО «Ингосстрах»

4 комментария

• АСН Администратор

  Уважаемый автор, сообщите, пожалуйста, когда вопрос можно будет считать решенным.

• АСН Администратор

  Уважаемая Елена, был ли решен вопрос?

• Елена (гость)

  Не удалось загрузить данные в РСА:
  ORA-20777: Значение не соответствует шаблону (номер телефона)

• Татьяна (гость)

  Добрый день. Не могу оформить полис ОСАГО появляется ошибка «ORA-20777: Значение не соответствует шаблону (Основной документ ТС. VIN)»

Номер
Ошибка
Решение

1
Ошибка регистрации пациента для свидетельства […]
Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус»

2
Не найден CDA-документ
Повторить процедуру формирования и подписания ЭД

3
CertificateType certificateType, Decimal certificateId, String certificateIdString, Int32 maxTimeoutMs, ProcessingContext processingContext
Не заполнен / некорректно заполнен раздел «Профессиональное образование» или «Сертификаты» регистра кадров.
Необходимо проверить корректность введения данных в разделе «Регистр кадров» (данные подтягиваются из модуля «Регистр медицинских работников»). Профессиональное образование и сертификаты

4

Ошибка при формирование ЭД свидетельства о смерти:

System.Exception: Ошибка регистрации пациента для свидетельства #11732280240: {«Message»:[«Неправильный идентификатор системы»]}

at CdaGetter.Middleware.GetCdaMiddleware.GetCdaAsyncCore

Неправильный идентификатор системы / Отсутствует связь с МИС.
Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус», указав OID организации и код мединфо.

5

Exception EOleException in module p8561vcl.bpl at 0046E539.

Параметр задан неверно.

Некорректно заданы настройки криптопровайдера или установлена не поддерживаемая версия.
Если на ПК установлен Крипто-Про и VipNet CSP, то в VipNet CSP в меню «Дополнительно» снять галочку с опции «Поддержка работы VipNet CSP через Microsoft CryptoAPI» 2.) Если VipNet CSP отсутсвует, переустановить Крипто-Про.

6
Данные документа идентичны переданным ранее
Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус» с указанием, какие именно изменения вносились в свидетельство.

7
Ожидание CDA по свидетельству продлилось больше 30000.
Системная ошибка Нетрики. Повторить процедуру формирования и подписания ЭД

8
HTTP request failed
Техническая ошибка на стороне сервисов. Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус». 

9
System.Exception: Ошибка при формировании блока сведений по сотруднику […]
Расхождение данных ФРМО / ФРМР и данных в модулях «Паспорт ЛПУ», «Регистр медицинских работников» — раздел «Регистром кадров».
Необходимо проверить по сотруднику данные по исполнениям должностей. Данные в «Регистре медицинских работников, раздел Регистр кадров» должны полностью совпадать с данными в продуктивном контуре ФРМР (Дата начала, Должность, Структурное подразделение, кол-во ставок, Тип занятости). После приведения данных в соответствие, повторно сформировать электронный документ.

10

Поле «State» заполнено некорректно.

DeadInfo.AddressDto.State»,»Поле «State» заполнено некорректно.

Ошибка связана с некорректным заполнением Адреса, (регион. улица).
Необходимо заполнять адрес согласно справочнику «Географические понятия»

11
The element type «hr» must be terminated by the matching end-tag «</hr>».
Ошибка связана с несоответствием данных в ФРМР и регистром кадров (регистром медицинских работников).
Необходимо актуализировать информацию на ФРМР. Данные должны соответствовать регистру медицинских работников. После — повторить процедуру создания электронного документа и его подписание.

12
Сертификаты недоступны. В окне выбора сертификатов нет доступных записей.
Не выполнены рекомендации, указанные в руководстве пользователя по пункту «Подготовительный этап работ».
Необходимо выполнить пункт 3.1.3.1 «Подготовительный этап работ» руководства пользователя

13
Object reference not set to an instance of an object.
Несоответствие данных в ФРМО и ФРМР с «Регистром медицинских работников», «Паспорт ЛПУ».
Необходимо актуализировать информацию на ФРМР и ФРМО. Данные должны соответствовать модулю «Регистр медицинских работников» и «Паспорт ЛПУ». После — повторить процедуру создания электронного документа и его подписание.

14
Документ заблокирован другим пользователем
Ошибка говорит о том, что документ открыт у других пользователей. Необходимо закрыть документ под другими пользователями и повторить процедуру формирования и подписания ЭД.

15
В сертификате отсутствует атрибут «OGRN»
При использовании ЭЦП руководителя не обнаружен реквизит «ОГРН». Необходимо подписывать ЭЦП, содержащей указанный атрибут. 

16
Поле «Middle Name» заполнено некорректно. Recipient.Person.HumanName.MiddleName
Во вкладке «Получатель» некорректно заполнено поле «Фамилия», «Имя» или «Отчество». Необходимо внести корректировки на вкладке «Получатель»: некорректно заполнено поле «Фамилия», «Имя» или «Отчество».

17
Ошибка поиска должности (…) сотрудника […] на дату XX.XX.XXXX в регистре кадров»
У сотрудника (…) на XX.XX.XXXX нет действующей должности ‘….’. Необходимо указать в свидетельстве одну из должностей, которая действует на эту дату. 

18

System.Exception: Подпись врача не найдена.

at CdaSender.Middleware.SendMiddleware.GetRequestDataAsync(Decimal rn, CertificateType certificateTy

Ошибка возникает по причине некорректного указания должности для сотрудников, заполненных по полям «Лицо, заполнившее свидетельство», «Лицо, выдавшее свидетельство», «Лицо, установившее смерть».
Вкладка «Медицинский персонал». Для сотрудников, указанных в полях «Лицо, заполнившее свидетельство», «Лицо, выдавшее свидетельство», «Лицо, установившее смерть» запрещено указывать должности, относящиеся к блоку «Руководители медицинских организаций». Необходимо внести корректировки по полю «Должность». ФЛК на стороне подсистемы «Демография» будет доработан в ближайшее время.

19
RUNTIME_ERROR; Message: Непредвиденная ошибка
Подобного рода ошибки возникают в тот момент, когда ЭД был отправлен в ФРЭМД, но при этом федеральный сервис был в этот момент не доступен. При этом в сервисе Нетрики происходит автоматическая переотправка таких документов. Со стороны пользователя дополнительных действий не требуется. Необходимо дождаться статуса документа, когда он либо будет «Принят ЕГИСЗ», либо «Ошибка ЕГИСЗ» (с описание корректной причины отказа в принятии документа). Если в «Журнале сообщений» нет записей, необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус».

20
Неверный СНИЛС = ошибка в вычислении контрольной суммы
Не пройдена проверка на соблюдение контрольной суммы указанного СНИЛС. Необходимо произвести корректировки в поле «СНИЛС». ФЛК на стороне подсистемы «Демография» будет доработан в ближайшее время.

21
Неверный формат SOAP-сообщения ответа поставщика (unmarshalling): The element type «hr» must be terminated by the matching end-tag «</hr>».
Отсутствие доступа к федеральному сервису в момент отправки документа. Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка автоматически со стороны интеграционного шлюза.

22
Поле Id Document Type заполнено некорректно. Recipient.Person.DocumentsDto[1].IdDocumentType

Некорректно указан тип документа, удостоверяющего личность. Необходимо внести корректировки по полю «Тип документа, удостоверяющего личность».

23
Поле ‘Birth Area’ заполнено некорректно. NbInfo.BirthArea.
Не заполнено поле «Местность» блока «Адреса». Документ «Свидетельство о рождении», на вкладке «Даные ребенка» необходимо указать «Местность». 

24
[«Указан некорректный номер Медицинского свидетельства о рождении. Допустимо использовать значение, соответствующее регулярному выражению ^[2]{1}[0-9]{8,9}$. DocN»]
С 1.03.2022 введена новая нумерация медицинских свидетельств о рождении. В связи с этим свидетельства со старыми номерами, не отправленные до 1 марта, невозможно выгрузить в региональную систему Нетрика. Выгружайте свидетельства, выданные после 1 марта.

25
Ошибка отправки:
<s:Envelope xmlns:s=»http://schemas.xmlsoap.org/soap/envelope/»><s:Body><s:Fault><faultcode>s:Client</faultcode><faultstring xml:lang=»ru-RU»>Создатель этой ошибки не указал Reason.</faultstring><detail><RequestFault xmlns=»http://schemas.datacontract.org/2004/07/N3.EMK.Dto.Common» xmlns:i=»http://www.w3.org/2001/XMLSchema-instance»><PropertyName/><Message>Произошла техническая ошибка</Message><ErrorCode>99</ErrorCode><Errors/></RequestFault></detail></s:Fault></s:Body></s:Envelope>

Техническая ошибка. Необходимо заново нажать на документе ПКМ — Электронный документ — Сформировать и отправить ЭД — ОК.

При этом статус документа должен быть автоматически сменён на «Передача данных в ЕГИСЗ»

26
Code: NOT_UNIQUE_PROVIDED_ID; Message: Документ с идентификатором ‘…’ уже зарегистрирован
Данный документ был успешно зарегистрированы в РЭМД, но статус от федерального сервиса не пришел. При этом в сервисе Нетрики происходит автоматическая переотправка таких документов. Со стороны пользователя дополнительных действий не требуется. Необходимо дождаться статуса документа, когда он либо будет «Принят ЕГИСЗ», либо «Ошибка ЕГИСЗ» (с описание корректной причины отказа в принятии документа). Если в «Журнале сообщений» нет записей, необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус».

27
Code: PERSON_POST_IN_FRMR_MISMATCH; Message: Указанная должность сотрудника не соответствует занимаемой им должности в организации […] на дату создания документа […] по данным ФРМР. Сотрудник с индексом

Расхождение данных на продуктивном контуре ФРМР и данных в подсистеме «Демография» по блоку «Медперсонал».

Необходимо проверить сведения по сотрудникам в разделе «Регистр кадров»:

• Исполнение должности. Должность работника МО

Данные в «Регистре кадров» должны полностью совпадать с данными в продуктивном контуре ФРМР на дату выдачи свидетельства. После приведения данных в соответствие, повторно сформировать электронный документ. 

28
PERSON_CARD_NOT_FOUND; Message: По данным REST-службы ФРМР на дату создания документа […] отсутствует личное дело сотрудника с индексом [0]

Расхождение данных на продуктивном контуре ФРМР и данных в подсистеме «Демография» по блоку «Медперсонал».

Необходимо проверить сведения по сотрудникам в разделе «Регистр кадров»:

• ФИО
• Дата рождения
• Пол
• СНИЛС
• Исполнение должности. Должность работника МО
• Исполнение должности. Структурное подразделение
• Профессиональное образование. Специальность

Данные в «Регистре кадров» должны полностью совпадать с данными в продуктивном контуре ФРМР на дату выдачи свидетельства. После приведения данных в соответствие, повторно сформировать электронный документ. 

29
System.Exception: Ошибка регистрации пациента для свидетельства #: {«Message»:[«Rest Request to MPI return status code BadRequest. Content: {«resourceType»:»OperationOutcome»,»issue»:[{«severity»:»error»,»code»:»value»,»details»:{«coding»:[{«system»:»http://hl7.org/fhir/issue-type»,»code»:»value»}]},»diagnostics»:»Parameter Patient.BirthDate content is invalid»},{«severity»:»error»,»diagnostics»:»Parameter Patient.BirthDate content is invalid»}]}»]}
Ошибка может возникает в случае, если личность пациента не установлена.
Выгрузка свидетельств для пациентов с неустановленной личностью в данный момент не поддерживается федеральной системой. В случае, если личность пациента не установлена, свидетельство не подлежит выгрузке в формате электронного документа.

30
System.Exception: Ошибка регистрации пациента для свидетельства #: {«Message»:[«Rest Request to MPI return status code Forbidden. Content: {«resourceType»:»OperationOutcome»,»issue»:[{«severity»:»error»,»code»:»forbidden»,»details»:{«coding»:[{«system»:»http://hl7.org/fhir/issue-type»,»code»:»forbidden»}]},»diagnostics»:»Unauthorized»},{«severity»:»error»,»diagnostics»:»Unauthorized»}]}»]}
Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус»

31
Code: FILE_WAS_NOT_SENT; Message: РМИС/МИС не передала файл ЭМД
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

32
callback:
Code: GET_DOCUMENT_FILE_ERROR; Message: Сервис предоставляющей ИС не доступенjava.lang.IllegalArgumentException: Невозможно вызвать операцию getDocumentFile callback-сервиса РМИС версии 3.0. Адрес сервиса: https://ips.rosminzdrav.ru/644401e0fba9a. Ошибка: connect timed out. Тип ошибки: SocketTimeoutException
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

33
callback:
Доступ к сервису временно запрещён — для системы, соответствующей идентификатору c4e06f16-7ff5-4610-b664-04180756f025, превышен лимит запросов к сервису
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

34
В случае возникновения ошибки: callback: Code: VALIDATION_ERROR; Message: Ошибки валидации в ФРМСС:[code: MSSCERT, description: Внутренняя ошибка сервиса ФРМСС, уникальный идентификатор ошибки: aa21f6cc-55ed-4e15-a25c-931d71d48004].
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

35
Code: PATIENT_CREATION_ERROR; Message: Внутренняя ошибка ГИП при создании пациента
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

36
Code: INTERNAL_ERROR; Message: Внутренняя ошибка системы
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

37
System.Exception: Error while executing SQL non query: ORA-20103: Недопустимо изменение параметра ID_PATIENT
Если по свидетельству был получен CDA-документ, а после были внесены правки по пациенту (умершему), то для повторного переформирования электронного документа необходимо обратиться к сотрудникам МИАЦ для внесения изменений в Регистре пациентов (Нетрика), после изменений данных в их системе, переформировывать CDA в Демографии и заново повторить отправку документа

38
System.Exception: Ошибка отправки свидетельства #**********: {«Message»:[«Идентификатор пациента в запросе не совпадает с ранее зарегистрированным»]}
Если по свидетельству был получен CDA-документ, а после были внесены правки по пациенту (умершему), то для повторного переформирования электронного документа необходимо обратиться к сотрудникам МИАЦ для внесения изменений в Регистре пациентов (Нетрика), после изменений данных в их системе, переформировывать CDA в Демографии и заново повторить отправку документа

39
Удаление свидетельства
Для удаления свидетельства необходимо обратиться к сотруднику МИАЦ, Клевко Василию Александровичу.

40
Удалить электронный документ

Необходимо оформить Заявка.docx и направить в МИАЦ.

Для получения локального идентификатора необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус»

41
Ошибка отправки свидетельства #********: {«Message»:[«Поле «Death Area» заполнено некорректно. DeadInfo.DeathArea»]}
Не заполнено поле «Местность». Документ «Свидетельство о смерти», на вкладке «Адреса» необходимо указать «Местность».

42
Code: VALIDATION_ERROR; Message: Ошибки валидации в ФРМСС:[code: DUPLICATE, description: Свидетельство с номером [ ] и серией [ ] уже зарегистрировано]

Ответ от СТП ЕГИСЗ:

Данная проблема известна, работы по ее устранению уже ведутся.
Ошибка будет устранена в одном из ближайших релизов. После обновления системы будет опубликована соответствующая новость на портале СТП ЕГИСЗ (https://support.egisz.rosminzdrav.ru)
Следите за новостями.
Приносим извинения за доставленные неудобства.

43
System.Exception: Ошибка отправки свидетельства #*********: {«Message»:[«Поле ‘Registry Area’ заполнено некорректно. MotherInfo.RegistryArea»]}

Свидетельство о рождении, закладки: данные матери — не заполнено поле «Местность».

По обязательности заполнения поля «Местность» был сделан запрос в СТП ЕГИСЗ (#886057), на который получен ответ:

«В Руководстве по реализации СЭМД «Медицинское свидетельство о рождении» Редакция 4, действительно, указание местности регистрации матери является обязательным.»

44
Поле ‘Mother Occupation’ заполнено некорректно. MotherInfo.MotherOccupation
Некорректно заполнено поле «Занятость матери». Недопустимо использовать значение «Неизвестно». 

45
Ошибка при обмене данными: SocketException: Обрыв канала (Write failed)
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

46
The request channel timed out attempting to send after 00:01:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

47
Превышено время ожидания ответа поставщика
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

48
Ошибки валидации в ФРМСС:[code: MSSCERT, description: Введенные данные не удовлетворяют ограничению [frmss.cert.ch4cert8receiver_fio] уникальный идентификатор ошибки: b9281110-4040-4bee-ba90-c0a0e22d3af1]

Заявка в СТП ЕГИСЗ #860376.

Ответ от СТП ЕГИСЗ:

Уважаемый пользователь.

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

49
Code: RUNTIME_ERROR; Message: Internal error
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

50
Не удалось построить цепочку сертификатов до Головного УЦ(сертификат организации выдан не аккредитованным УЦ или один из сертификатов цепочки не действителен)
Для регистрации документа в РЭМД необходимо, чтобы подпись МО и сотрудников действовала на дату создания ЭМД и дату регистрации ЭМД в РЭМД.

В данном случае тип ошибки определяется ответом от УЦ, мы уже работаем над исправлением отправляемого кода ошибки.

Документы, согласно пп 140, необходимо регистрировать в РЭМД в течении 1 суток с момента их создания.
Однако, согласно ФЗ-63 и подчиненным актам ФСБ — при проверки подписи, подпись должна быть действительна, то есть если врач подписал ЭМД, далее у него истекла подпись и далее направить документ на регистрацию, то такой документ зарегистрирован не будет, так как проверка подписи, осуществляемая сертифицированными криптографическими средствами, выполнена не будет.

51
CryptoProSigner timeout exception
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза

52
System.ArgumentException: Документ с таким NRN отсутвует в базе
Вкладка Медперсонал, блок Руководитель, должен быть указан руководитель организации.

53
В регистре найдено медицинское свидетельство о рождении с указанными серией и номером. Необходимо исправить серию и номер
Документ «Сведения о бумажном МСР» зарегистрирован в РЭМД. Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус» с перечнем номеров свидетельств для смены статусов в подсистеме Демография.

54

Сертификат сотрудника не действителен на дату создания документа /

Сертификат МО не действителен на дату создания документа

Необходимо проверить действие исполнения должности, указанной в свидетельстве у всех сотрудников с вкладки Медперсонал.  Если условие соблюдено, направить список номеров свидетельств в СТП Парус.

55
Данные документа с IdDocumentType = 14 различаются в MotherInfo и Recipient.
Свидетельство о рождении, вкладка «Данные матери» поле код подразделения не должно быть пустым.

56
Доступ к сервису временно запрещён — для системы, соответствующей идентификатору ***********************, превышен лимит запросов к сервису
Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза.

57
Message»:[«Поле ‘Issued Date’ не может быть пустым. DeadInfo.Person.DocumentsDto[0].IssuedDate»]
Отсутствует дата выдачи документа, удостоверяющего личность. 

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

• Проверить, что поле, в которое заносится электронный адрес непустое (поскольку пользователь может просто забыть ввести адрес, и, если этот случай необработан, возникнет ошибочная ситуация);
• Проверить соответствие введенного адреса с помощью регулярного выражения.

Проверка на пустоту поля

Проверка того, что пользователь ввел данные, может осуществляться, с помощью функции isset:

<?php
  $name = $_POST['name'];
  if (!isset($name))
  {
    // если переменная $name не существует, просим повторить ввод имени
?>
    <h1>Пожалуйста введите ваше имя!</h1>
    <!-- далее следует HTML-код формы, в которой вводится имя -->
<?php
  }
  else
  {
    -
  }
?>

На практике удобно сначала проверить, не пустой ли action формы, а потом уже проверять различные его составляющие: поле имя, e-mail и т.д. К примеру:

<?php
  $action = $_POST["action"];
  if (!empty($action)) 
  {
    if (empty($name)) 
    {
     // код, для случая, когда не введено имя
    }
    if (empty($email))
    {
       // код, для случая, когда не введен e-mail
    }
  // дальнейший код скрипта
  }
  if (empty($action)) 
  {
?>
  <!-- здесь пишем HTML-код формы, в которой вводится информация -->
<?php
  }
?>

Проверка допустимости вводимых данных

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

Адрес должен иметь вид Walls.234@mail.ru. У адреса две составляющие — имя пользователя и имя домена, которые разделены знаком «@». В имени пользователя могут присутствовать буквы нижнего и верхнего регистров, цифры, знаки подчеркивания, минуса и точки.

Для проверки разделителя между именем пользователя и именем домена в выражение требуется добавить +@. Регулярное выражение, проверяющее имя пользователя и наличие разделителя имеет вид:

 "/[0-9a-z_]+@[0-9a-z_^.]"

Для проверки доменного имени добавляем выражение:

 ".[a-z]{2,3}/i"

Объединяя эти выражения, получаем регулярное выражение для проверки адресов электронной почты:

 "/[0-9a-z_]+@[0-9a-z_^.]+.[a-z]{2,3}/i"

Проверка файлов

Для файловых полей используются те же самые проверки, что и для обычных, однако они применяются уже не к собственно содержимому поля, а к массиву $_FILES, поэтому инструкции для файловых полей должны иметь специальную структуру. Рассмотрим в качестве примера следующую HTML-форму:

<form method="POST" enctype="multipart/form-data">
    ...
    <input type="file" name="photo">
    ...
</form>

Массив $_FILES для такой формы в случае успешной загрузки файла будет иметь такой вид:

Array
{
    [photo] => Array
        {
            [name] => britney 100x100.jpg
            [type] => image/jpeg
            [tmp_name] => /tmp/php1AD.tmp
            [error] => 0
            [size] => 2752
        }

}

Чтобы сделать загрузку файла обязательной, в список инструкций нужно добавить элемент «*»:

'photo' => array{
        '*' => 'Нужно загрузить файл.',
        'name' => array{
                '/.(jpeg|png)$/i' => 'Файл должен быть в формате JPEG или PNG.',
                // Для такой проверки можно было использовать и type 
                // принципиальной разницы нет, т.к. элемент type
                // генерируется сервером на основе расширения файла.
            },
        'size' => array{
                '< ' . (1024 * 1024) => 'Файл {*name*} слишком большой, максимум - 1 Мб.',
                // Метка {*name*} заменится на исходное имя загруженного файла  
            },
    }

Если проверка на загрузку как таковую является единственной, инструкцию для поля можно записывать в сокращенной форме:

'photo' => 'Нужно загрузить файл.'

Проверка изображений

Если предполагается загрузка изображения, можно выполнить ряд проверок некоторых его свойств, используя для этого специальный тип инструкций файлового поля. Это обычные инструкции, которые будут анализировать данные, полученные с помощью функции getimagesize(). В результате своей работы она возвращает массив следующего вида:

Array
{
    [0] => 450
    [1] => 675
    [2] => 2
    [3] => width="450" height="675"
    [bits] => 8
    [channels] => 3
    [mime] => image/jpeg
}

Предположим, нужно убедиться, что изображение нужного типа, и, кроме того, ограничить его максимальные размеры форматом 2048х1536. Чтобы выполнить все эти проверки, нужно включить в инструкции для файлового поля специальный элемент — «image»:

'photo' => array{
        'image' => array{
                '*' => 'Файл "{*name*}" не является изображением или поврежден.',
                'mime' => array{
                        '/jpeg|png/' => 'Изображение должно быть в формате JPEG или PNG.'
                        // Нужно сказать, что getimagesize() устанавливает mime-type файла
                        // на основе анализа его содержимого (определяется верно даже 
                        // при неправильном расширении), поэтому для проверки типа изображения 
                        // лучше использовать результат работы getimagesize(), 
                        // а не содержимое $_FILES.
                    },
                'width' => array{
                        '<= 2048' => 'Ширина изображения не должна превышать 2048 px.', 
                    },
                'height' => array{
                        '<= 1536' => 'Высота изображения не должна превышать 1536 px.',
                    },
            },
    }

Ключи «width» и «height» используются в качестве псевдонимов для ключей 0 и 1 исходного массива от getimagesize().

Вот именно с помощью таких проверок в php можно защитить от несанкцианированного доступа на Ваш сайт, а также от непонимающих и забывающих вводить нужные данные пользователей.

Обычные посетители сайта обращают внимание в первую очередь на качественный контент, а поисковые краулеры – на ответы сервера.

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

Немного теории

Определить доступность веб-страницы поможет анализ кода состояния HTTP. Технически он представляет из себя стандартный запрос. Он отправляется, когда мы переходим по определенной ссылке на сайте или просто вводим ее в поисковой строке браузера. При обработке запроса сервер самостоятельно формирует и отдает трехзначный цифровой код.

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

Сперва определимся с терминами.

• Клиент – компьютер, смартфон или другое мобильное устройство, которое имеет подключение к интернету.
• Сервер – определенный компьютер, который хранит все данные сайта (включая страницы и системные файлы). Именно на сервере «живет» сайт.

Выделяют пять классов ответов. Идентифицировать класс можно по первой цифре.

• 5** – техническая ошибка на стороне сервера. Точная причина указывается сразу после кода. Иногда пятисотая говорит о внутренних сбоях, реже – о превышении статической нагрузки на сервер.
• 4** – сбой на стороне юзера.
• 3** – обнаружен редирект на другой адрес (не ошибка).
• 2** – запрос обработан успешно (не ошибка).
• 1** – служебный класс кодов, который чаще всего относится к информационным сообщениям (не ошибка).

Логика кодов, таким образом, весьма проста:

Что значат коды состояния HTTP

Причины / решения / пояснения ошибок, я буду давать только для самых часто встречающихся кодов. Для всех остальных – только краткое описание.

Двухсотые – успешные запросы

200 – успешный запрос данных. Код не является ошибкой.

201 – завершена успешная транзакция. Код говорит о том, что сформирован новый ресурс (или документ).

202 – запрос принят, но еще не завершен. Необходимо дождаться окончания обработки.

203 – данные получены не из первоисточника (возвращаемые данные идут не от исходного сервера, а от какого-то другого) и могут быть устаревшими.

204 – запрос был обработан правильно, но отсутствует содержимое. Есть заголовок ответа, но содержимое для него отсутствует. Обновлять и актуализировать содержимое не нужно.

205 – клиенту необходимо осуществить сброс содержимого. Саму страницу обновлять не требуется.

206 – ошибка частичного содержимого. Если клиент хочет выполнить загрузку данных в несколько потоков, а сервер выполняет только часть GET-запроса, будет возникать 206-ая ошибка.

GET-запрос предназначен для получения данных, в то время как POST-запрос нужен для отправки данных.

Код также может быть отправлен с сервера, когда клиент запросил диапазон (например, условно: «Дайте мне первые 2 МБ видеоданных»). Происходит возврат только частичного контента, соответствующего Range-заголовку (данный заголовок дает понять серверу, какую именно часть страницы от него требуют, и какую ему нужно вернуть).

Если страница отдает этот код, следует обратить внимание на выполнение кэширования и на исходящий запрос.

207 – выполнено несколько операций. Найти их можно в XML, в строке MultiStatus.

226 – обработан IM-заголовок. Содержимое будет возвращено для получения информации об ответе вместе с ранее обозначенными параметрами.

Трехсотые – запросы на редирект

300 – не удалось идентифицировать точный URL. Такой ответ возникает, когда существует множественный выбор, и краулер не знает, к какой именно странице относится ресурс.

301 – документ был навсегда перемещен на новый URL. Так должны отвечать все веб-страницы, которые удалены или являются зеркалами, дублями. Со временем все указанные страницы будут склеены с целевой веб-страницей (присоединены к ней) автоматически. Если возникает такая ошибка, нужно настроить 301-ое перенаправление с устаревшего URL на актуальный (если речь идет о веб-странице, которая уже ранжировалась, но ее URL изменился). В таком случае все позитивные метрики, включая вес URL, будут сохранены.

302 – документ был временно перемещен на новый URL. Это абсолютно корректный ответ сервера, который актуален для веб-страниц с распродажами или сезонными акциями, распространяющимися на какой-либо товар. Код указывает, что данный URI будет учитываться клиентом в последующих запросах. Другими словами, страница была найдена, но перенесена. Такие документы из индекса не удаляются. Если адрес был изменен навсегда, вместо 302-го, лучше использовать 303-ий или 307-ой ответ.

303 – нужно направить пользователя на иной URL. 303-ый код можно получить исключительно GET-запросом. В идеале, этот код нужно отдавать, когда требуется редиректнуть посетителя на близкорелевантую, но не идентичную странице.

304 – документ не модифицировался. Этот код не является стандартным редиректом. Он помогает краулерам определять страницы, которые не изменились с последнего визита.

Если на вашем сайте немного страниц (до 1 000), использовать код 304 нет смысла. Если вас напрягает этот редирект, то в заголовке нужно поправить параметр Last-Modified (последняя дата изменения) – он не должен быть старше, чем заголовок If-Modified-Since (если изменялся спустя заданное количество времени).

305 – доступ к этому документу возможен исключительно через прокси.

307 – документ был временно перемещен на иной URL. Идеальный вариант, если требуется временно редиректнуть посетителя, но оставить техническую возможность отправки POST-запросов.

Четырехсотые – сбои на стороне клиента

400 – ошибка синтаксиса. Сервер не может идентифицировать запрос, так как была допущена опечатка в синтаксисе. Проверьте корректность отправляемого запроса.

401 – отсутствует аутентификация. Код отдается, когда для доступа требуется пароль или регистрация.

403 – отсутствует доступ к документу. Возникает, когда пользователь хочет открыть системные файлы (robots, htaccess). Либо вы сделали опечатку при вводе URL и пытаетесь воспользоваться веб-страницей, которая не предназначена для обычного пользователя, либо вам нужно: пройти авторизацию для доступа к системным файлам.

404 – отсутствует соответствующий ресурс по введенному URL. Разберитесь, по каким причинам была удалена / перемещена страница. Возможно, вы допустили ошибку и удалили ее случайно. Если так – просто восстановите ее.

Задумайтесь над созданием красивой, кастомизированной 404-ой. Например, такой:

405 – некорректный метод (указывается в запросной строке клиента) для выбранного документа. Метод запроса определяет точное действие, которое должно быть выполнено для указанного ресурса.

406 – некорректный / неподдерживаемый краулером формат запроса. Код отдается, когда сервер не способен возвратить ответ, релевантный листу допустимых значений. Самый распространенный случай – поисковый робот не поддерживает кодировку документа или его язык. Убедитесь, что в теле сообщения содержится лист доступных ресурсов. Подробное описание ошибка на сайте веб-разработчиков Mozilla.

407 – отсутствует регистрация прокси или авторизация файервола.

408 – таймаут запроса. Соединение разорвано, так как полный запрос не был передан. Другими словами, запрос занял слишком много времени, а сервер не готов был ждать. На каждом сайте существует свое время таймаута. Проверьте наличие интернета и просто обновите страницу. Подробное объяснение этой ошибки на сайте веб-разработчиков Mozilla.

409 – несовместимость двух запросов. Запрос невозможно выполнить при текущем состоянии сервера. Самый распространенный случай – операции c PUT-запросом. Например, когда нужно скачать файл, возраст которого превышает возраст уже существующего, расположенного на сервере.

410 – ресурс более не существует по указанному URL. Если страница удаляется целенаправленно, лучше делать так, чтобы она отдавала именно 410-ый. Краулер обойдет такую страницу, получит этот код и больше никогда на нее не вернется, так как поймет, что она удалена навсегда. Если речь о веб-странице, которая была удалена временно, гораздо эффективнее использовать 404-ый ответ. Если страница удалена намерено и навсегда, но в SERP имела хорошие места и приносила трафик, лучше сделать редирект на максимально релевантную существующую страницу.

411 – сервер сам отклоняет отправляемый запрос, так как не находит значение Content-Length. Этот ответ характерен как для обычных POST-запросов, так и для PUT-запросов (подразумевают замену существующих представлений документа на данные, которые содержатся в самом запросе).

412 –не были до конца выполнены условные поля HTTP-заголовка, например, If-Match. 412-ый код появляется в случаях, когда доступ к целевому документу отклоняется. Нужно проверить соблюдение и корректность HTTP-заголовков выполняемого запроса.

413 – у каждого сервера есть свой собственный максимальный размер запроса, определяемый не самим HTTP-протоколом (у него ограничения по длине запроса просто напросто отсутствуют), а ограничениями со стороны браузеров. Браузеры поддерживают запросы от 2 до 8 килобайт. Вышеуказанный код отдается, когда сервер не понимает запрос из-за слишком большого размера.

414 – возникает, когда отправляется чрезвычайно длинный URL. Запросы, содержащие излишне длинные URL, не могут правильно интерпретироваться сервером. Самые частые случаи появления этого ответа – попытка передать удлиненные параметры (излишне большое количество данных через GET- запрос).

415 – некорректный медиаформат. Текущий тип данных не может быть интерпретирован сервером.

416 – некорректное значение Range (диапазон). Ответ возникает в случаях, когда в самом HTTP-заголовке прописывается некорректный байтовый диапазон. 416-ый отдается в случаях, когда сервер не может взаимодействовать с запрашиваемыми диапазонами. Причина – отсутствие диапазона в необходимом документе или опечатка в синтаксисе.Сервер просто не имеет возможности работать с запрашиваемыми диапазонами. Проверьте синтаксис значения Range – он должен обязательно соблюдаться. Скорее всего, документ просто не имеет запрашиваемых диапазонов. Обновите страницу.

417 – указанное значение Expect не может быть удовлетворено (речь о заголовке запроса). Прокси некорректно идентифицировал содержимое поля «Expect: 100-Continue». Устранить эту ошибку самостоятельно не удастся. Если вы используете прокси Squid, обратитесь в поддержку. Вам нужно активировать ignore_expect_100. Другой вариант ­ разрешите BS_PingHost обращаться к интернет-сети без участия прокси.

422 – существует определенная логическая ошибка. Какая именно, данный код не указывает. Копайте в сторону ошибок в семантике документа.

423 – используемый ресурс был заблокирован для выбранного HTTP—метода. Перезагрузите роутер и компьютер. Используйте только статистический IP.

424 – зависимый ресурс был блокирован по соображением безопасности. Данный код отдается, если в запросе присутствуют признаки несанкционированного доступа к файлам CMS.

426 – некорректные значения полей Upgrade и Conection. Этот ответ возникает, когда серверу требуется обновление до SSL-протокола, но клиент не имеет его поддержки.

429 – слишком много запросов. Ошибка отдается, когда один пользователь проявляет чрезмерно большую активность за короткий временной интервал. Проверьте плагины используемой CMS. В идеале, отключите их все и включайте по очереди, пока не доберетесь до источника проблемы.

451 – доступ к серверу заблокирован по решению судебных органов. Можно плодить бесконечные дубли или вообще создать новый домен, но рано или поздно страницу с идентичным содержимым все равно заблокируют. Временное решение – разместить проблемное содержимое на другом домене. Провайдеры могут подстраховаться и блокировать не только отдельные страницы, но и сайты целиком. Не нарушать закон – единственное, что можно посоветовать в этом случае.

Пятисотые – серверные сбои

500 – серверу не удается полностью обработать запрос. Такой код отдается, когда существует непредвиденное условие, мешающее выполнению запроса. Чаще всего внутренняя ошибка сервера может появляться при серверных сбоях. Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess), нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

Проверяйте конфликты плагинов и дополнений. Нередко 500-ая возникает, когда в настройках административной панели хостинга указана одна версия PHP, а на самом сайте используется другая. Последнее также создает высокую статическую нагрузку на хостинг. Если вам было бы узнать о пятисотой подробнее, пишите в комментариях, и я напишу развернутый материал на эту тему.

501 – не выполнено. Этот код отдается, когда сам сервер не может идентифицировать метод запроса. Сами вы эту ошибку не исправите. Устранить ее может только сервер.

502 – шлюзовый сбой. Возникает при получении некорректного ответа от сервера, находящегося по иерархии выше. Актуально исключительно для прокси и шлюзовых конфигураций.

503 – данный ответ возникает в случаях, когда существуют технические неполадки, не позволяющие интерпретировать введенный запрос. Скорее всего, ваш сервер просто на обслуживании или сильно перегружен. Уменьшите число перманентных запросов к базам данных. Убедитесь, что на сервере нет профилактических или других работ, ограничивающих его пропускную способность. Не используйте VPN.

504 – отсутствует ответ. Этот код отдается в одной ситуации – если сервер не может получит ответ за необходимый период времени. Отклика нет и возникает таймаут. Как и 501-ый ответ, 504-ый исправить самостоятельно не получится. Здесь дело в прокси, часто – в веб-сервере. Первым делом просто обновите веб-страницу. Если не помогло, нужно почистить DNS-кэш. Для этого используем сочетание горячих клавиш Windows+R и вводим команду cmd (Control+пробел). В открывшемся окне указываем команду ipconfig / flushdns и подтверждаем ее нажатием Enter.

Также полезно посмотреть, как страница ведет себя различных мобильных устройствах и в разных браузерах. Проверьте дебаг. Если сайт на WP, то проверить дебан проще всего. Достаточно добавить этот код в wp-config.php:

Теперь все сбои будут фиксировать в файле debug.log (находится в папке wp-сontents). Если вы используете другую CMS, найдите к ней мануал и посмотрите, как активировать в ней журнал ошибок.

Также 504-ая отдает, когда на сайте существуют проблемы, связанные с задействованием CDN или кастомизированных серверов DNS. Отключите CDN на своем сайте.

Иногда 504-ый код пропадает, если просто подождать несколько часов. Часто 504-ая появляется на сайтах, которые используют CloudFlare.

505 – отсутствует поддержка текущей версии HTTP-протокола.

507 – не хватает места на жестком диске для выполнения запроса.

510 – не найдено расширение, желающее задействовать клиент.

Массово проверяем ответ веб-страницы

Самый простой способ проверить ответ веб-страницы – воспользоваться готовыми сервисами. Наиболее популярны:

• mainspy;
• 2ip;
• cy-pr;
• wwhois;
• 4seo.

Возьмем для примера mainspy. Тут проверить код ответа проще всего:

Таким образом, для проверки кода просто открываем страницу и вводим необходимые URL. Кликаем «Проверить». Будет выведен отчет. Напротив каждого проверяемого URL будет отображаться код ответа сервера:

Кроме перечисленных сервисов есть также замечательный плагин для Google Chrome – HTTP Header Spy. Он позволяет проверять код ответа сервера как одной, так и нескольких страниц сразу:

Послесловие

Коды ответа HTTP – это универсальный язык, который понимают не только краулеры Google / «Яндекса», но и люди. 5 классов кодов позволят с первого взгляда определить, где именно существует ошибка при выполнении HTTP запроса и куда копать для ее устранения.

Если ваш код ответа не указан в этом мануале, значит речь идет о кастомизированном сервере. Чтобы правильно истолковать ответ такого сервера и перевести его на человеческий язык, придется обратится к его разработчику.

	Не идет обмен между базами Я
aleks100 28.09.21 — 10:04	Не идет обмен между Згу 3.1.18.216 и бгу 2.0.80.31. Не выгружается документ отражение зарплаты в учете. Не могу понять, может правила обновить?
aleks100 1 — 28.09.21 — 10:12	обмен идет через каталог, почему в зарплате пишет данные отправлены и получены, а в бухгалтерии только отправлены, но не получены
hhhh 2 — 28.09.21 — 10:16	(1) это то как раз правильно, если обмен не идет, то она и не пишет, что получено, всё логично.
aleks100 3 — 28.09.21 — 10:24	может правила обмена обновить?
aleks100 4 — 28.09.21 — 10:24	или вручную выгрузить?
hhhh 5 — 28.09.21 — 10:38	(4) ну вы ошибку озвучьте, которая в журнале регистрации, чего гадать?
aleks100 6 — 28.09.21 — 10:40	Не удалось выполнить отправку данных. Подробности см. в журнале регистрации
hhhh 7 — 28.09.21 — 10:40	(4) а, конечно, вручную попробовать. Об этом и спрашивать не надо.
aleks100 8 — 28.09.21 — 10:40	Ошибка, Отправка данных; Объектов обработано: 0
hhhh 9 — 28.09.21 — 10:44	(8) вы получение смотрите, а не отправку. Не отвлекайтесь. Ошибка же при получении.
patapum 10 — 28.09.21 — 10:46	(6) Значит надо посмотреть пару сообщений перед этим, в них информация об ошибке.
aleks100 11 — 28.09.21 — 10:58	а как выгрузить один документ через универсальный обмен?
aleks100 12 — 28.09.21 — 11:06	почему то на стороне бухгалтерии обмен не идет
hhhh 13 — 28.09.21 — 11:13	(12) вы же это уже писали в (0). Запускайте вручную в бухгадтерии.
SleepyHead 14 — 28.09.21 — 11:14	(12) а он точно видит входящее сообщение? Может, там права на папку отвалились.
aleks100 15 — 28.09.21 — 11:18	(14) в бгу  пишет данные не получены, обмен идет из ЗГУ в БГУ
aleks100 16 — 28.09.21 — 11:19	(13) что значит вручную в бухгалтерии?
SleepyHead 17 — 28.09.21 — 11:42	(15) Видно ли из БГУ папку, в которую ЗУП выложила файл обмена?
hhhh 18 — 28.09.21 — 11:46	(16) обмен как запускаете в бухгалтерии?
timurhv 19 — 28.09.21 — 11:54	(15) >в бгу  пишет данные не получены, обмен идет из ЗГУ в БГУ Подробности из журнала регистрации будут? Обычно, в БГУ период закрывают, а из зарплаты пытаются выгрузить старый документ.
Pro-tone 20 — 28.09.21 — 11:56	(0) вангую, что обмен по правилам КД2, там тогда можно протокол выполнения подключить, либо он уже есть и нужно только в него посмотреть, это текстовый файл, куда логи обмена пишет, включая подробное описание ошибок
aleks100 21 — 28.09.21 — 12:04	кто-то дату установил  дату запрета на 31 августа в бгу, а документ отражения зп в учете за август, может из-за этого не выгружает
aleks100 22 — 28.09.21 — 12:06	пытался вручную документ добавить, смотрю а он не добавляется
aleks100 23 — 28.09.21 — 12:16	выгрузил,из-за даты запрета документы не выгружались

О том, как можно проверять значения, введёные пользователем

В любых программных продуктах, будь то windows-приложение или web-сайт, получение информации от пользователей зачастую осуществляется с помощью форм ввода данных.

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

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

На практике это выливается с довольно длинные последовательности «if-else». Лично мне это жутко не нравилось, так как сложно с первого взгляда определить, какие поля как проверяются и какие сообщения выдаются в случае ошибок. А ведь полей в форме может быть и десять, тогда код проверки вообще затягивается. Вобщем, я задумался над тем, как можно минимизировать объём работ и вот что из этого получилось.

Я представил проверку как преобразование значения одного типа в значение другого типа (например, проверка того, что в поле введено чило, это преобразование строки в число). Тоесть проверка — это некая функция, имеющая сигнатуру делегата System.Converter<T, U>.

Для проверки значение помещаем в класс обёртку:

Суть проверки заключается в последовательном вызове методов-расширений для объектов класса ValidationStep<T>, которые опять же возращают объект класса ValidationStep<T>. Это позволяет создавать цепочки проверок. Вот пример таких методов-расширений:

Первый метод используется, чтобы можно было проверять объекты любых типов, торой метод осуществляет проверку на соответствие предикату, а третий на возможность преобразования значения из одного типа в другой. Также можно написать любые другие проверки, например на соответствие целого числа диапазону. Главное, что в случае неудачной проверки должно возникать исключение ValidationException, которое содержит сообщение с текстом ошибки.

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

А теперь о том, как это использовать. Допустим нам нужно проверить текстовое поле (tb1) и убедиться, что в него введено целое число в диапазоне от 0 до 10. Это можно сделать так:

Учитывая, что проверок может быть больше, да и число полей в форме, как правило, больше одного, такой способ проверок может быть очень даже удобен.

Проверка корректности данных

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

• Проверить, что поле, в которое заносится электронный адрес непустое (поскольку пользователь может просто забыть ввести адрес, и, если этот случай необработан, возникнет ошибочная ситуация);
• Проверить соответствие введенного адреса с помощью регулярного выражения.

Кроме чистых ошибок пользователя, необходимо также исключить ситуации, в которых возможно злонамеренное введение некорректных данных, к примеру, различных скриптов. Для этого вводимый пользователем текст необходимо обработать функциями удаления HTML-тегов (для исключения возможности написания скриптов на JavaScript и Visual Basic) и обратных слешей (для исключения возможности написания скриптов на Perl). Т. о. минимальный набор действий, необходимый для проверки корректности данных, вводимых пользователем, включает следующие этапы:

• проверка того, что пользователь ввел данные
• проверка допустимости вводимых пользователем данных (как правило, осуществляется при помощи регулярных выражений)
• обработка текста, введенного пользователем функцией htmlspecialchars для удаления HTML-тегов
• обработка текста, введенного пользователем функцией stripslashes для удаления обратных слешей

Проверка на пустоту поля

Проверка того, что пользователь ввел данные, может осуществляться, к примеру, с помощью функции isset:

Для этой же цели можно использовать функцию empty:

На практике удобно сначала проверить, не пустой ли action формы, а потом уже проверять различные его составляющие: поле имя, e-mail и т. д. К примеру:

Проверка допустимости вводимых данных

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

Будем исходить из того, что адрес должен иметь вид something@server.com. Как видим, у адреса две составляющие — имя пользователя и имя домена, которые разделены знаком @. В имени пользователя могут присутствовать буквы нижнего и верхнего регистров, цифры, знаки подчеркивания и минуса, точки. Для проверки разделителя между именем пользователя и именем домена в выражение требуется добавить +@. Таким образом, регулярное выражение, проверяющее имя пользователя и наличие разделителя имеет следующий вид:

Для проверки доменного имени добавляем такое выражение:

Объединяя эти шаги, получаем следующее регулярное выражение для проверки адресов электронной почты:

Точно таким же образом вы можете проверить и остальные заполняемые пользователем поля.

Удаление HTML — тегов и обратных слешей

Как уже говорилось, вводимый пользователем текст необходимо обработать функциями удаления HTML-тегов (для исключения возможности написания скриптов на JavaScript и Visual Basic) и обратных слешей (для исключения возможности написания скриптов на Perl). К примеру, если переменная $name содержит текст с именем пользователя, то обработка этого текста выглядит так:

Если Вам нужна частная профессиональная консультация от авторов многих книг Кузнецова М.В. и Симдянова И.В., добро пожаловать в наш Консультационный Центр SoftTime.

Динамические формы — проверка ввода на JavaScript

При разработке страниц, содержащих HTML формы ввода, нужно всегда помнить, что есть обязательная информация, есть необязательная. Если пользователь при вводе, например, не заполнит обязательное поле «email», то на сервере в момент отработки скрипта и записи в базу данных может возникнуть ошибка.

Как правило, разработчики Web-приложений учитывают это, и если какие-то данные не были приняты на сервере CGI-скриптом, то последний возвращает опять страницу с «руганью» и формой для дозаполнения, тем самым избегая ошибки времени исполнения на сервере.

Но каждая передача данных на сервер — это лишнее время (с точки зрения пользователя), и лишняя загрузка сервера, на котором исполняется CGI-скрипт, что опять-таки за собой тянет увеличение времени ожидания. Поэтому, имея практически на каждом компьютере такие мощные средства, как JavaScript, реализованные в браузерах версий 4 и выше, вполне можно заставлять страницу саму себя проверять на корректность ввода данных в формы.

Известно, что HTML документ имеет объектно-ориентированную структуру, а посему, с помощью свойств и методов можно проверять объекты типа «элемент формы» на наличие в них данных.

В первую очередь, форма.

Стоит обратить внимание на две вещи:

1. Вызов функции checkform() на событие onSubmit(т.е. на нажатие кнопки Submit)
2. Атрибут required в двух полях — Name и E-mail

Значит в момент отправки формы вызывается функция checkform(). Вот она:

В общем — все понятно: передаем в качестве параметра форму, перебираем все элементы, если элемент имеет атрибут required, — проверяем его функцией isEmpty(). Если функция возвращает истину, — то строка пустая, если нет — то заполнена. Если строка пустая, то имя этого поля добавляется в переменную errMSG. Если errMSG оказывается не пустой строкой, то выводим сообщение об ошибке, и возвращаем в форму false, вследствие чего форма не отправляется на сервер.

Проверка правильности заполнения формы во время ввода

Можно проверять заполнение формы во время ввода данных в элементы управления. При этом надо отрабатывать события на этих элементах.

В данном случае обрабатывается событие onKeyPress.:

Где event.keyCode = скан-код нажатой клавиши.

Можно проверять элементы формы во время заполнения формы. Для этого нужно отрабатывать событие OnChange:

В данном случае после изменения поля отрабатывает скрипт, который проверяет, что было введено — текст или число, и изменяет стиль оформления данного элемента управления.:

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

Содержание

Что такое код ответа HTTP

Как проверить код состояния страницы

В браузере

В Яндекс.Вебмастере

В Google Search Console

1* класс кодов (информационные сообщения)

100 Continue

101 Switching Protocols

102 Processing

103 Checkpoint

105 Name Not Resolved

2* класс кодов (успешно обработанные запросы)

200 ОК

201 Created

202 Accepted

203 Non‑Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

207 Multi‑Status

226 IM Used

3* класс кодов (перенаправление на другой адрес)

300 Multiple Choices

301 Moved Permanently

302 Found/Moved 

303 See Other

304 Not Modified

305 Use Proxy

306 Unused

307 Temporary Redirect

308 Resume Incomplete

4* класс кодов (ошибки на стороне клиента)

400 Bad Request

401 Unauthorized

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Request Entity Too Large

414 Request‑URI Too Long

415 Unsupported Media Type

416 Requested Range Not Satisfiable

417 Expectation Failed

418 I’m a teapot

422 Unprocessable Entity

423 Locked

424 Failed Dependency

425 Unordered Collection

426 Upgrade Required

428 Precondition Required

429 Too Many Requests

431 Request Header Fields Too Large

434 Requested Host Unavailable

444 No Response

449 Retry With

450 Blocked by Windows Parental Controls

451 Unavailable For Legal Reasons

456 Unrecoverable Error

499 Client Closed Request

5* класс кодов (ошибки на стороне сервера)

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout

505 HTTP Version Not Supported

506 Variant Also Negotiates

507 Insufficient Storage

508 Loop Detected

509 Bandwidth Limit Exceeded

510 Not Extended

511 Network Authentication Required

Составили подробный классификатор кодов состояния HTTP. Добавляйте в закладки, чтобы был под рукой, когда понадобится.

Что такое код ответа HTTP

Когда посетитель переходит по ссылке на сайт или вбивает её в поисковую строку вручную, отправляется запрос на сервер. Сервер обрабатывает этот запрос и выдаёт ответ — трехзначный цифровой код HTTP от 100 до 510. По коду ответа можно понять реакцию сервера на запрос. 

Первая цифра в ответе обозначает класс состояния, другие две — причину, по которой мог появиться такой ответ.

Как проверить код состояния страницы

Проверить коды ответа сервера можно вручную с помощью браузера и в панелях веб‑мастеров: Яндекс.Вебмастер и Google Search Console.

В браузере

Для примера возьмём Google Chrome.

1. Откройте панель разработчика в браузере клавишей F12, комбинацией клавиш Ctrl + Shift + I или в меню браузера → «Дополнительные инструменты» → «Инструменты разработчика». Подробнее об этом рассказывали в статье «Как открыть исходный код страницы». 

2. Переключитесь на вкладку «Сеть» в Инструментах разработчика и обновите страницу: 

В Яндекс.Вебмастере

Откройте инструмент «Проверка ответа сервера» в Вебмастере. Введите URL в специальное поле и нажмите кнопку «Проверить»:

Как добавить сайт в Яндекс.Вебмастер и другие сервисы Яндекса

В Google Search Console

Чтобы посмотреть код ответа сервера в GSC, перейдите в инструмент проверки URL — он находится в самом верху панели:

Введите ссылку на страницу, которую хотите проверить, и нажмите Enter. В результатах проверки нажмите на «Изучить просканированную страницу» в блоке «URL есть в индексе Google».

А затем в открывшемся окне перейдите на вкладку «Подробнее»:

Теперь расскажем подробнее про все классы кодов состояния HTTP.

1* класс кодов (информационные сообщения)

Это системный класс кодов, который только информирует о процессе передачи запроса. Такие ответы не являются ошибкой, хотя и могут отображаться в браузере как Error Code.

100 Continue

Этот ответ сообщает, что полученные сведения о запросе устраивают сервер и клиент может продолжать отправлять данные. Такой ответ может требоваться клиенту, если на сервер отправляется большой объём данных.

101 Switching Protocols

Сервер одобрил переключение типа протокола, которое запросил пользователь, и в настоящий момент выполняет действие.

102 Processing

Запрос принят — он находится в обработке, и на это понадобится чуть больше времени.

103 Checkpoint

Контрольная точка — используется в запросах для возобновления после прерывания запросов POST или PUT.

105 Name Not Resolved

Не удается преобразовать DNS‑адрес сервера — это  означает ошибку в службе DNS. Эта служба преобразует IP‑адреса в знакомые нам доменные имена.

2* класс кодов (успешно обработанные запросы)

Эти коды информируют об успешности принятия и обработки запроса. Также сервер может передать заголовки или тело сообщений. 

200 ОК

Все хорошо — HTTP‑запрос успешно обработан (не ошибка).

201 Created

Создано — транзакция успешна, сформирован новый ресурс или документ.

202 Accepted

Принято — запрос принят, но ещё не обработан.

203 Non‑Authoritative Information

Информация не авторитетна — запрос успешно обработан, но передаваемая информация была взята не из первичного источника (данные могут быть устаревшими).

204 No Content

Нет содержимого — запрос успешно обработан, однако в ответе только заголовки без контента сообщения. Не нужно обновлять содержимое документа, но можно применить к нему полученные метаданные.

205 Reset Content

Сбросить содержимое. Запрос успешно обработан — но нужно сбросить введенные данные. Страницу можно не обновлять.

206 Partial Content

Частичное содержимое. Сервер успешно обработал часть GET‑запроса, а другую часть вернул.

При работе с подобными ответами следует уделить внимание кэшированию.

207 Multi‑Status

Успешно выполнено несколько операций — сервер передал результаты выполнения нескольких независимых операций. Они появятся в виде XML‑документа с объектом multistatus. 

226 IM Used

Успешно обработан IM‑заголовок (специальный заголовок, который отправляется клиентом и используется для передачи состояния HTTP).

3* класс кодов (перенаправление на другой адрес)

Эти коды информируют, что для достижения успешной операции нужно будет сделать другой запрос, возможно, по другому URL.

300 Multiple Choices

Множественный выбор — сервер выдает список нескольких возможных вариантов перенаправления (максимум — 5). Можно выбрать один из них.

301 Moved Permanently

Окончательно перемещено — страница перемещена на другой URL, который указан в поле Location.

302 Found/Moved 

Временно перемещено — страница временно перенесена на другой URL,  который указан в поле Location.

303 See Other

Ищите другую страницу — страница не найдена по данному URL, поэтому смотрите страницу по другому URL, используя метод GET.

304 Not Modified

Модификаций не было — с момента последнего визита клиента изменений не было.

305 Use Proxy

Используйте прокси — запрос к нужному ресурсу можно сделать только через прокси‑сервер, URL которого указан в поле Location заголовка.

306 Unused

Зарезервировано. Код в настоящий момент не используется.

307 Temporary Redirect

Временное перенаправление — запрашиваемый ресурс временно доступен по другому URL.

Этот код имеет ту же семантику, что код ответа 302 Found, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если в первом запросе использовался POST, то во втором запросе также должен использоваться POST.

308 Resume Incomplete

Перемещено полностью (навсегда) — запрашиваемая страница была перенесена на новый URL, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается.

4* класс кодов (ошибки на стороне клиента)

Эти коды указывают на ошибки со стороны клиентов. 

400 Bad Request

Неверный запрос — запрос клиента не может быть обработан, так как есть синтаксическая ошибка (возможно, опечатка).

401 Unauthorized

Не пройдена авторизация — запрос ещё в обработке, но доступа нет, так как пользователь не авторизован.

Для доступа к запрашиваемому ресурсу клиент должен представиться, послав запрос, включив при этом в заголовок сообщения поле Authorization.

402 Payment Required

Требуется оплата — зарезервировано для использования в будущем. Код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний.

403 Forbidden

Запрещено — запрос принят, но не будет обработан, так как у клиента недостаточно прав. Может возникнуть, когда пользователь хочет открыть системные файлы (robots, htaccess) или не прошёл авторизацию.

404 Not Found

Не найдено — запрашиваемая страница не обнаружена. Сервер принял запрос, но не нашёл ресурса по указанному URL (возможно, была ошибка в URL или страница была перемещена).

405 Method Not Allowed

Метод не разрешён — запрос был сделан методом, который не поддерживается данным ресурсом. Сервер должен предложить доступные методы решения в заголовке Allow.

406 Not Acceptable

Некорректный запрос — неподдерживаемый поисковиком формат запроса (поисковый робот не поддерживает кодировку или язык).

407 Proxy Authentication Required

Нужно пройти аутентификацию прокси — ответ аналогичен коду 401, только нужно аутентифицировать прокси‑сервер.

408 Request Timeout

Тайм‑аут запроса — запрос клиента занял слишком много времени. На каждом сайте существует свое время тайм‑аута — проверьте интернет‑соединение  и просто обновите страницу.

409 Conflict

Конфликт (что‑то пошло не так) — запрос не может быть выполнен из‑за конфликтного обращения к ресурсу (несовместимость двух запросов).

410 Gone

Недоступно — ресурс раньше был размещён по указанному URL, но сейчас удалён и  недоступен (серверу неизвестно месторасположение).

411 Length Required

Добавьте длины — сервер отклоняет отправляемый запрос, так как длина заголовка не определена, и он не находит значение Content‑Length. 

Нужно исправить заголовки на сервере, и в следующий раз робот сможет проиндексировать страницу.

412 Precondition Failed

Предварительное условие не выполнено — стоит проверить правильность HTTP‑заголовков данного запроса.

413 Request Entity Too Large

Превышен размер запроса — перелимит максимального размера запроса, принимаемого сервером. Браузеры поддерживают запросы от 2 до 8 килобайт.

414 Request‑URI Too Long

Превышена длина запроса — сервер не может обработать запрос из‑за длинного URL. Такая ошибка может возникнуть, например, когда клиент пытается передать чересчур длинные параметры через метод GET, а не POST.

415 Unsupported Media Type

Формат не поддерживается —  сервер не может принять запрос, так как  данные подгружаются в некорректном формате, и сервер разрывает соединение.

416 Requested Range Not Satisfiable

Диапазон не поддерживается — ошибка возникает в случаях, когда в самом HTTP‑заголовке прописывается некорректный байтовый диапазон.

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

417 Expectation Failed

Ожидания не оправдались — прокси некорректно идентифицировал содержимое поля «Expect: 100‑Continue».

418 I’m a teapot

Первоапрельская шутка разработчиков в 1998 году. В расшифровке звучит как «я не приготовлю вам кофе, потому что я чайник». Не используется в работе.

422 Unprocessable Entity

Объект не обработан — сервер принял запрос, но в нём  есть логическая ошибка. Стоит посмотреть в сторону семантики сайта.

423 Locked

Закрыто — ресурс заблокирован для выбранного HTTP‑метода. Можно перезагрузить роутер и компьютер. А также использовать только статистический IP.

424 Failed Dependency

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

Выполнение запроса напрямую зависит от успешности выполнения другой операции, и если она не будет успешно завершена, то вся обработка запроса будет прервана.

425 Unordered Collection

Неверный порядок в коллекции — ошибка возникает, если клиент указал номер элемента в неупорядоченном списке или запросил несколько элементов в порядке, отличном от серверного.

426 Upgrade Required

Нужно обновление — в заголовке ответа нужно корректно сформировать поля Upgrade и Connection. 

Этот ответ возникает, когда серверу требуется обновление до SSL‑протокола, но клиент не имеет его поддержки.

428 Precondition Required

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

429 Too Many Requests

Слишком много запросов — отправлено слишком много запросов за короткое время. Это может указывать, например, на попытку DDoS‑атаки, для защиты от которой запросы блокируются.

431 Request Header Fields Too Large

Превышена длина заголовков — сервер может и не отвечать этим кодом, вместо этого он может просто сбросить соединение.

Исправляется это с помощью сокращения заголовков и повторной отправки запроса.

434 Requested Host Unavailable

Адрес запрашиваемой страницы недоступен.

444 No Response

Нет ответа — код отображается в лог‑файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение. Возвращается только сервером nginx.

Nginx — программное обеспечение с открытым исходным кодом. Его используют для создания веб‑серверов, а также  в качестве почтового или обратного прокси‑сервера. Nginx решает проблему падения производительности из‑за роста трафика. 

449 Retry With

Повторите попытку — ошибка говорит о необходимости скорректировать запрос и повторить его снова. Причиной становятся неверно указанные параметры (возможно, недостаточно данных).

450 Blocked by Windows Parental Controls

Заблокировано родительским контролем — говорит о том, что с компьютера попытались зайти на заблокированный ресурс. Избежать этой ошибки можно изменением параметров системы родительского контроля.

451 Unavailable For Legal Reasons

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

456 Unrecoverable Error

Неустранимая ошибка — при обработке запроса возникла ошибка, которая вызывает некорректируемые сбои в таблицах баз данных.

499 Client Closed Request

Запрос закрыт клиентом — нестандартный код, используемый nginx в ситуациях, когда клиент закрыл соединение, пока nginx обрабатывал запрос.

5* класс кодов (ошибки на стороне сервера)

Эти коды указывают на ошибки со стороны серверов. 

При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя. И его можно использовать в работе.

500 Internal Server Error

Внутренняя ошибка сервера — сервер столкнулся с неким условием, из‑за которого не может выполнить запрос. 

Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess) и нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

501 Not Implemented

Не выполнено —  код отдается, когда сам сервер не может идентифицировать метод запроса. 

Сами вы эту ошибку не исправите. Устранить её может только сервер.

502 Bad Gateway

Ошибка шлюза — появляется, когда сервер, выступая в роли шлюза или прокси‑сервера, получил ответное сообщение от вышестоящего сервера о несоответствии протоколов.

Актуально исключительно для прокси и шлюзовых конфигураций.

503 Service Unavailable

Временно не доступен — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). 

В поле Retry‑After заголовка сервер укажет время, через которое  можно повторить запрос.

504 Gateway Timeout

Тайм‑аут шлюза —  сервер, выступая в роли шлюза или прокси‑сервера, не получил ответа от вышестоящего сервера в нужное время.

Исправить эту ошибку самостоятельно не получится. Здесь дело в прокси, часто — в веб‑сервере. 

Первым делом просто обновите веб‑страницу. Если это не помогло, нужно почистить DNS‑кэш. Для этого  нажмите горячие клавиши Windows+R и введите команду cmd (Control+пробел). В открывшемся окне укажите команду ipconfig / flushdns и подтвердите её нажатием Enter.

505 HTTP Version Not Supported

Сервер не поддерживает версию протокола — отсутствует поддержка текущей версии HTTP‑протокола. Нужно обеспечить клиента и сервер одинаковой версией.

506 Variant Also Negotiates

Неуспешные переговоры — с такой ошибкой сталкиваются, если сервер изначально настроен неправильно. По причине ошибочной конфигурации выбранный вариант указывает сам на себя, из‑за чего процесс и прерывается.

507 Insufficient Storage

Не хватает места для хранения — серверу недостаточно места в хранилище. Нужно либо расчистить место, либо увеличить доступное пространство.

508 Loop Detected

Обнаружен цикл — ошибка означает провал запроса и выполняемой операции в целом.

509 Bandwidth Limit Exceeded

Превышена пропускная способность —  используется при чрезмерном потреблении трафика. Владельцу площадки следует обратиться к своему хостинг‑провайдеру. 

510 Not Extended

Не продлён — ошибка говорит, что на сервере отсутствует нужное для клиента расширение. Чтобы исправить проблему, надо убрать часть неподдерживаемого расширения из запроса или добавить поддержку на сервер.

511 Network Authentication Required

Требуется аутентификация — ошибка генерируется сервером‑посредником, к примеру, сервером интернет‑провайдера, если нужно ввести пароль для получения доступа к сети через платную точку доступа.