Andreas Schildbach [ARCHIVE] on Nostr: 📅 Original date posted:2012-01-31 📝 Original message:On 01/31/2012 11:22 AM, ...
📅 Original date posted:2012-01-31
📝 Original message:On 01/31/2012 11:22 AM, Wladimir wrote:
> To ensure forward compatibility with optional fields, we need to define
> how a client handles fields that it doesn't know about.
>
> When should it display an error message, and when should it silently
> accept and ignore the extraneous fields?
IMHO its standard that unknown URL parameters are simply ignored. I
think we should not change this principle.
> (For example, if something that restricts the validity, such
> as "expires" is added later on, it is pretty important not to ignore it.
> Older clients should refuse to comply.)
In this case, you'd need to refuse *all* parameters you don't know
about. In consequence, all extensions would break older clients.
📝 Original message:On 01/31/2012 11:22 AM, Wladimir wrote:
> To ensure forward compatibility with optional fields, we need to define
> how a client handles fields that it doesn't know about.
>
> When should it display an error message, and when should it silently
> accept and ignore the extraneous fields?
IMHO its standard that unknown URL parameters are simply ignored. I
think we should not change this principle.
> (For example, if something that restricts the validity, such
> as "expires" is added later on, it is pretty important not to ignore it.
> Older clients should refuse to comply.)
In this case, you'd need to refuse *all* parameters you don't know
about. In consequence, all extensions would break older clients.