Which RFC document could I use for relative URL conflict?

Question

First of all, I saw several question related RFC in SO, but if this question not belong to here, instead downvoting it, please moderate/flag/move it to other stack site. (Thanks!)

I'm having a very long-term issue with an application (my application, suppose called "B") that receives URLs in a content from other application (application "A").

A (theirs) ---> B (mine) ---> C lient

Now the client requires me that fix the problem, and a discussion about which team needs fix this situation was generated.

For the business and policy of my business, I can't handle the content, so I must NOT touch the content generated in the application "A". I can do it but breaking the policy, so, is not an option.

The content, as I said, is generated in application "A", so, this policy is not concerned to them.

THE PROBLEM:

When a user is generating content, uploads an image that is stored on "A" server. So, they have relative urls, as: "/A_server_folder/image.jpg"

When I receive the content, the content said the same, not an absolute url, like "A_SERVER_DOMAIN/A_server_folder/image.jpg"

so...

QUESTION

I remember a RFC saying something about "be strict when you send data and polite when you receive it". But... there is any RFC related about this problem? Somewhere where it sais "the owner of the original system must provide an absolute url and not a relative url to indicate their own path?"

I want attach this RFC or RFC article to the business policy to answer the other team. As I said, is not about the problem itself, is very easy for me change the url, but I could get in really legal trouble if I parse the content.

Thanks and kind regards

Answer 1

What you're referring to is called the Robustness Principle:

Be conservative in what you send, be liberal in what you accept.

Because it's vague, it's not really an RFC requirement, it's just a general design philosophy. However, you can find it in RFC 761, the specification of TCP. RFC 1122, Requirements for Internet Hosts, expands on it:

Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue.