Re: SPARQL protocol and HTTP Update : HTML file upload

On 26/11/10 18:45, Chimezie Ogbuji wrote:
> On 11/25/10 9:45 AM, "Andy Seaborne"<andy.seaborne@epimorphics.com>  wrote:
>>>> Is this in/out scope for the SPARQL protocol and SPARQL HTTP Update?
>>>>
>>>> It would be good for standard, documented behavior here.  What is needed is:
>>>>
>>>> 1/ Note that the 2 specs do apply to multipart/form-data
>>>> 2/ Define it so every content-disposition: filename= means load
>>>>     as per POST for each of the SPARQL protocols.
>>> This seems sensible,
>
> Seems sensible to me as well.
>
>>> I see filename= as problematic though, as we really need
>>> a URI in there for it to be useful.
>>
>> filename is part of RFC1867 and is supplied by the browser.
>
> Do browsers typically return *just* the filename or do they return a URI
> using the file: scheme? If it is the former, then I would think the base
> resolution mechanism should be enough to determine the full URI for the
> target named graph.  If it is the latter, then I agree that this would be
> problematic since you couldn't reasonably interpret the request as
> indicating that the client has identified a resource on the server to
> modify.
>
>> I have a prototype that adds a form field named-graph-uri (same name as
>> SPARQL query protocol, different meaning).  If it's "", absent or
>> "default" it means the default graph.
>
> So, would a request with named-graph-uri = 'default' and a filename= trigger
> a 400 (Bad Request)?
>
>> Would that be what you want?  Tricky for more than one file but we could
>> just restrict ourselves to one file for some text.
>
> I think we would want (for HTTP/Update, anyways) to restrict to only one
> file.
>
>> 3/ Define a form field "graph-uri"
>
> Is that needed? Assuming, filename= can provide a fully qualified (HTTP) URI
> or if just the filename is provided, the base resolution mechanism would be
> able to determine the target named graph being modified/added, then it seems
> that the only additional parameter we need is one to indicate whether or not
> the embedded content is meant for the default graph (default-graph or
> something similar)
>
> -- Chime

FF and Chrome provide the local file name without path.  They always 
provide it (it's not a field the form has - its added by the browser):

 From the RFC:

<FORM ACTION="http://server.dom/cgi/handle"
       ENCTYPE="multipart/form-data"
       METHOD=POST>
What is your name? <INPUT TYPE=TEXT NAME=submitter>
What files are you sending? <INPUT TYPE=FILE NAME=pics>
</FORM>

which has no mention of "filename" leads to:

--AaB03x
content-disposition: form-data; name="pics"; filename="file1.txt"
Content-Type: text/plain

... contents of file1.txt ...
--AaB03x--

As it's just the directory local name it seems fairly useless for graph 
naming.  I don't see why it should have any natural correspondence - it 
might be a temporary working file used to prepare the data.

Worse, because there is no content type, it's going to be used for 
guessing the serialization syntax. My experience is that you can't rely 
on "Content-Type" (I get application/octet-stream when uploading D.ttl). 
And I don't want the ".ttl" to be part of the external graph name :-)

Wouldn't base name resolution limit that to an IRI under the base name 
so I think we need a mechanism to pass over an IRI regardless for when 
the user wishes to explicitly choose the name by giving a full IRI 
somehow.

Steve's "graph=" is a better name.  It can be absent but in an HTML page 
form fields can't be turned off (without javascript) can they?  That's 
what prompted "" or the word "default" for the default graph.

The protocol ignore filename= for naming purposes.

Do other browsers do anything different?

	Andy

Received on Friday, 26 November 2010 19:52:18 UTC