1

I recently read some of : https://www.rfc-editor.org/rfc/rfc6570#section-1

And I found the following URL template examples :

GIVEN : 
  var="value"; 
  x=1024; 
  path=/foo/bar;

{/var,x}/here         /value/1024/here  
{#path,x}/here        #/foo/bar,1024/here

These seem contradictory.

In the first one, it appears that the / replaces , In the 2nd one, it appears that the , is kept .

Thus, I'm wondering wether there are inconsistencies in this particular RFC. I'm new to these RFC's so maybe I don't fully understand the culture behind how these develop.

Community
  • 1
  • 1
jayunit100
  • 17,388
  • 22
  • 92
  • 167

1 Answers1

2

There's no contradiction in those two examples. They illustrate the point that the rules for expanding an expression whose first character is / are different from the rules for expanding an expression whose first character is #. These alternative expansion rules are pretty much the entire point of having a variety of different magic leading characters -- which are called operators in the RFC.

The expression with the leading / is expanded according to a rule that says "each variable in the expression is replaced by its value, preceded by a / character". (I'm paraphrasing the real rule, which is described in section 3.2.6 of that RFC.) The expression with the leading # is expanded according to a rule that says "each variable in the expression is replaced by its value, with the first variable preceded by a # and subsequent variables preceded by a ,. (Again paraphrased, see section 3.2.4 for the real rule.)

ottomeister
  • 5,415
  • 2
  • 23
  • 27