Какой документ RFC я могу использовать для относительного конфликта URL?

Question

Прежде всего, я видел несколько вопросов, связанных с RFC в SO, но если этот вопрос здесь не относится, вместо того, чтобы понижать его, пожалуйста, модерируйте /flag/ переместите его на другой сайт стека. (Спасибо!)

У меня очень долгая проблема с приложением (мое приложение, предположительно, называется "B"), которое получает URL-адреса в контенте из другого приложения (приложение "A").

A (их) ---> B (мой) ---> C lient

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

Для бизнеса и политики моего бизнеса я не могу обрабатывать контент, поэтому я не должен касаться контента, сгенерированного в приложении "А". Я могу сделать это, но нарушать политику, так что это не вариант.

Контент, как я уже сказал, генерируется в приложении "А", поэтому данная политика к ним не относится.

ЭТА ПРОБЛЕМА:

Когда пользователь генерирует контент, загружает изображение, которое хранится на сервере "А". Итак, у них есть относительные URL, такие как: "/A_server_folder/image.jpg"

Когда я получаю контент, контент говорит то же самое, а не абсолютный URL, как "A_SERVER_DOMAIN/A_server_folder/image.jpg"

так...

ВОПРОС

Я помню, что RFC говорил что-то вроде "будь строг, когда отправляешь данные, и вежлив, когда получаешь их". Но... есть ли RFC, связанные с этой проблемой? Где-то, где говорится "владелец исходной системы должен предоставить абсолютный URL, а не относительный URL, чтобы указать свой собственный путь?"

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

Спасибо и добрые пожелания

Answer 1

То, на что вы ссылаетесь, называется принципом робастности:

Будьте консервативны в том, что вы посылаете, будьте либеральными в том, что вы принимаете.

Поскольку это расплывчато, на самом деле это не требование RFC, это просто общая философия дизайна. Однако вы можете найти его в RFC 761, в спецификации TCP. RFC 1122, Требования к интернет-хостам, расширяет его:

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