[closed] Re: HTTP "related protocols?"

"Florent Georges" <fgeorges@fgeorges.org> writes:
>> One particular use case the WG had in mind here was accessing
>> non-XML content using computed URIs (for instance, from the file
>> system, using a "GET-like" access). You can use p:data for loading
>> binary data, but the disadvantage of p:data is that it can't take
>> URIs that are computed dynamically - whereas in the case of
>> p:http-request, the c:request element (and its "href" attribute)
>> can by generated dynamically.
>
>   Thanks for the explanation!  So if I am right, the intent of the
> step is "to perform HTTP and HTTPS requests, and support as well the
> file: scheme (in this case, @method is optional, and if present must
> be GET.)"
>
>   If it is, maybe it would be more clear to make the description in
> the CR more precise in that regard?  And maybe that trying to reuse
> http-request to support file: is just a kind of ad-hoc polymorphism?
> (so a separate step would maybe be better?)

We could have added a separate step. But given that lots of applications
that accept http: URIs also accept file: URIs, it didn't seem worth it.
And we didn't want to set the precedent that there should be a different
request step for every conceivable protocol.

Please let us know if you're not satisfied by this explanation.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The art of living is more like
http://nwalsh.com/            | wrestling than dancing.--Marcus Aurelius