Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #16221 > unrolled thread

How to send file content to server?

Back to article view | Back to comp.lang.javascript

Contents

  How to send file content to server? "Tom de Neef" <tdeneef@qolor.nl> - 2012-09-28 10:14 +0200
    Re: How to send file content to server? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-28 10:48 +0200
      Re: How to send file content to server? "Tom de Neef" <tdeneef@qolor.nl> - 2012-09-28 12:52 +0200
        Re: How to send file content to server? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-28 13:00 +0200
          Re: How to send file content to server? "Tom de Neef" <tdeneef@qolor.nl> - 2012-10-01 23:38 +0200
            Re: How to send file content to server? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-02 21:43 +0200
              Re: How to send file content to server? John G Harris <john@nospam.demon.co.uk> - 2012-10-03 16:15 +0100
              Re: How to send file content to server? "Tom de Neef" <tdeneef@qolor.nl> - 2012-10-03 19:06 +0200
                Re: How to send file content to server? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-03 20:20 +0200
                  Re: How to send file content to server? "Tom de Neef" <tdeneef@qolor.nl> - 2012-10-03 22:46 +0200
                    Re: How to send file content to server? "Tom de Neef" <tdeneef@qolor.nl> - 2012-10-04 07:50 +0200

#16221 — How to send file content to server?

I use code like this:
  var asyncRequestor = new XMLHttpRequest();
  var transmit = function(txt){
    asyncRequestor.open("POST",d2w.appID,true);
    asyncRequestor.setRequestHeader("Content-type","application/x-www-form-urlencoded");
    asyncRequestor.send(txt);
  };
  ...
  transmit('origin='+origin+'&'+args);
to pass information about events to the server. That works as required 
(thanks to help I got from you !).

Now I come to a point where the content of a file needs to be transmitted, 
like in:
  function readLocalFile(file) {
    var reader = new FileReader();
    reader.onload = 
function(){transmit('origin='+file.name+'&'+this.result)};
    reader.readAsBinaryString(file);
  }

Questions:
1. is this how a file's contents should be passed?
2. is the content-type still correct?
3. shouldn't this.result be encapsulated to cope with & and other unwanted 
chars?

Or maybe you can point me to an example. I could not find anything useful.
Thanks,
Tom

[toc] | [next] | [standalone]

#16224

Tom de Neef wrote:

> I use code like this:
>   var asyncRequestor = new XMLHttpRequest();
>   var transmit = function(txt){
>     asyncRequestor.open("POST",d2w.appID,true);
>     asyncRequestor.setRequestHeader("Content-type","application/x-www-
form-urlencoded");
>     asyncRequestor.send(txt);
>   };
>   ...
>   transmit('origin='+origin+'&'+args);
> to pass information about events to the server. That works as required
> (thanks to help I got from you !).
> 
> Now I come to a point where the content of a file needs to be transmitted,
> like in:
>   function readLocalFile(file) {
>     var reader = new FileReader();
>     reader.onload =
> function(){transmit('origin='+file.name+'&'+this.result)};
>     reader.readAsBinaryString(file);
>   }
> 
> Questions:
> 1. is this how a file's contents should be passed?

No.

> 2. is the content-type still correct?

No.

> 3. shouldn't this.result be encapsulated to cope with & and other unwanted
> chars?

Yes.  It should be URL-encoded instead, unless you gzip it.
 
> Or maybe you can point me to an example. I could not find anything useful.

<http://stackoverflow.com/a/8378918/855543>


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#16225

"Thomas 'PointedEars' Lahn wrote:
>
>> Now I come to a point where the content of a file needs to be 
>> transmitted,
>> like in:
>>   function readLocalFile(file) {
>>     var reader = new FileReader();
>>     reader.onload =
>> function(){transmit('origin='+file.name+'&'+this.result)};
>>     reader.readAsBinaryString(file);
>>   }
>>
>> Questions:
>> 1. is this how a file's contents should be passed?
> No.
>> 2. is the content-type still correct?
> No.
>> 3. shouldn't this.result be encapsulated to cope with & and other 
>> unwanted
>> chars?
> Yes.  It should be URL-encoded instead, unless you gzip it.
>> Or maybe you can point me to an example. I could not find anything 
>> useful.
> <http://stackoverflow.com/a/8378918/855543>
>

Whow ! 

[toc] | [prev] | [next] | [standalone]

#16226

Tom de Neef wrote:

> "Thomas 'PointedEars' Lahn wrote:
>>> Now I come to a point where the content of a file needs to be
>>> transmitted,
>>> like in:
>>>   function readLocalFile(file) {
>>>     var reader = new FileReader();
>>>     reader.onload =
>>> function(){transmit('origin='+file.name+'&'+this.result)};
>>>     reader.readAsBinaryString(file);
>>>   }
>>>
>>> Questions:
>>> […]1. is this how a file's contents should be passed?
>> No.
>>> 2. is the content-type still correct?
>> No.
>>> 3. shouldn't this.result be encapsulated to cope with & and other
>>> unwanted
>>> chars?
>> Yes.  It should be URL-encoded instead, unless you gzip it.
>>> Or maybe you can point me to an example. I could not find anything
>>> useful.
>> <http://stackoverflow.com/a/8378918/855543>
> 
> Whow !

Thanks.  Any questions as to that?


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#16299

"Thomas 'PointedEars' Lahn" wrote:
>
>>>pointer:  <http://stackoverflow.com/a/8378918/855543>
>>
>> Whow !
>
> Thanks.  Any questions as to that?
>

I can get this to work. (A related useful article that I found through your 
pointer was 
https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications).
But as you say in the reference, the prefered way is to let the work be done 
by the form's submit() method. Not only is it prefered, it is mandatory if 
you don't want to limit the use to the most modern browsers. IE8 doesn't 
support files, FileReader(), etc.
So I also played around with
<form action="someID?event=fileUpload" method="POST" 
enctype="multipart/form-data">  <input type="file" name="file">  <input 
type="submit"></form>On the server end, the processing is virtually the 
same. And it works: a true copy of the selected file ends up on the server. 
Ain't that marvellous!
Now for my ignorance: using the form submit, the connection will be 
terminated (gracefully) after the upload. (That does not happen when using 
the script route.) The transmission details of the submit() are:
POST /990727605?event=fileUpload HTTP/1.1
Host : 127.0.0.1:88
Connection : keep-alive
Content-Length : 3112
Content-Type : multipart/form-data; 
boundary=---------------------------18756118404966
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Start of POSTstream :
-----------------------------18756118404966
Content-Disposition: form-data; name="file"; filename="PRNshow.txt"
Content-Type: text/plain
<file contents>

My concern is that the server closes the connection after the submit(). Is 
that to be expected/can it be avoided? The detail says 'keep-alive'.
Where to go from here?
TIA
Tom 

[toc] | [prev] | [next] | [standalone]

#16320

Tom de Neef wrote:

> "Thomas 'PointedEars' Lahn" wrote:
>>>> pointer:  <http://stackoverflow.com/a/8378918/855543>
> […]
> 
> I can get this to work. (A related useful article that I found through
> your pointer was
> <https://developer.mozilla.org/
> en-US/docs/Using_files_from_web_applications>).

ACK.
 
> But as you say in the reference, the prefered way is to let the work be
> done by the form's submit() method. Not only is it prefered, it is
> mandatory if you don't want to limit the use to the most modern browsers.

You misunderstood.  I said that a form not using client-side scripting and 
only a plain submit button, or something else that submits the form is the 
*simplest* solution.  But it has the drawback that in many cases the file 
content must be transferred to the server before it can be decided whether 
the file should have been submitted in the first place.  And the server can 
only send (at least) one full HTML document as response.

If you use more advanced client-side scripting, you can reduce unnecessary 
roundtrips and provide immediate feedback to the user in case their user 
agents supports that.  Immediate feedback increases the responsiveness of 
the application, which in turn improves the user experience it provides.

> IE8 doesn't support files, FileReader(), etc.

True.  But that does not mean that other users cannot be provided with a 
better experience.  Graceful degration means that you can do a better thing 
without leaving the good one.

> So I also played around with
> <form action="someID?event=fileUpload" method="POST"
> enctype="multipart/form-data">  <input type="file" name="file">  <input
> type="submit"></form>On the server end, the processing is virtually the
> same. And it works: a true copy of the selected file ends up on the
> server. Ain't that marvellous!

Of course.  That has worked at least since HTML 4.01 became a W3C 
Recommendation (1999).

> Now for my ignorance: using the form submit, the connection will be
> terminated (gracefully) after the upload.

Most certainly it will not.  The HTTP version preferred by clients in user 
agents today is HTTP/1.1, which uses persistent connections per default.

> (That does not happen when using the script route.)

Ex falso quodlibet.

> The transmission details of the submit() are:
> POST /990727605?event=fileUpload HTTP/1.1
> Host : 127.0.0.1:88
> Connection : keep-alive

This header field is included in requests for compatibility with HTTP/1.0 
servers, and in responses for compatibility with HTTP/1.0 clients, 
respectively; see RFC 2068 (OBSOLETE), section 19.7.1.

> Content-Length : 3112
> Content-Type : multipart/form-data;
> boundary=---------------------------18756118404966
> Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Start of POSTstream :
> -----------------------------18756118404966
> Content-Disposition: form-data; name="file"; filename="PRNshow.txt"
> Content-Type: text/plain
> <file contents>
> 
> My concern is that the server closes the connection after the submit(). Is
> that to be expected/can it be avoided?

No/yes.

> The detail says 'keep-alive'.

Which is what most certainly happens.

> Where to go from here?

You should read RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1", section 
19.6.2, and sections and RFCs referred there.

<http://tools.ietf.org/html/rfc2616>


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#16346

On Tue, 2 Oct 2012 at 21:43:15, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:

  <snip>
>Ex falso quodlibet.
  <snip>

Now give us the classical Greek version.

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#16348

"Thomas 'PointedEars' Lahn" wrote:
>
>> [.]
>> But as you say in the reference, the prefered way is to let the work be
>> done by the form's submit() method. Not only is it prefered, it is
>> mandatory if you don't want to limit the use to the most modern browsers.
>
> You misunderstood.  I said that a form not using client-side scripting and
> only a plain submit button, or something else that submits the form is the
> *simplest* solution.  But it has the drawback that in many cases the file
> content must be transferred to the server before it can be decided whether
> the file should have been submitted in the first place.  And the server 
> can
> only send (at least) one full HTML document as response.
>
> If you use more advanced client-side scripting, you can reduce unnecessary
> roundtrips and provide immediate feedback to the user in case their user
> agents supports that.  Immediate feedback increases the responsiveness of
> the application, which in turn improves the user experience it provides.
>
>> IE8 doesn't support files, FileReader(), etc.
>
> True.  But that does not mean that other users cannot be provided with a
> better experience.  Graceful degration means that you can do a better 
> thing
> without leaving the good one.

You are right. But you missed my point: I need to get the html <form> submit 
alternative working because that _is_ the fall-back. And I could not get it 
to work.

>> So I played around with
>> <form action="someID?event=fileUpload" method="POST"
>>           enctype="multipart/form-data">
>>    <input type="file" name="file">
>>    <input type="submit">
>> </form>

>> And it works: a true copy of the selected file ends up on the
>> server. Ain't that marvellous!
>
> Of course.  That has worked at least since HTML 4.01 became a W3C
> Recommendation (1999).

Still: marvellous !

The key problem:
>> using the form submit, the connection will be terminated (gracefully)
>> after the upload.

As you have responded: it should not ! And I have failed to find the cause. 
But I have found a workaround:
in the <form> element I now specify a hidden <iframe> as target.
This may be amateuristic but it works and after ten days of experimenting I 
will leave it at that. (I blame the server software.)

Thank you very much for your suggestions, corrections and pointers.
A small piece of feedback for future references: in your post 
<http://stackoverflow.com/a/8378918/855543>
where you describe the file upload script principles, I think that the 
argument to the XMLHttpRequest().send() call should be terminated with a 
nlcr and closing boundary string.

Tom 

[toc] | [prev] | [next] | [standalone]

#16351

Tom de Neef wrote:

> "Thomas 'PointedEars' Lahn" wrote:
> […] I need to get the html <form> submit alternative working because that
> _is_ the fall-back. And I could not get it to work.

Then you are doing something wrong server-side, or have not explained your 
goal in enough detail.
 
>>> So I played around with
>>> <form action="someID?event=fileUpload" method="POST"
>>>           enctype="multipart/form-data">
>>>    <input type="file" name="file">
>>>    <input type="submit">
>>> </form>
>>> 
>>> And it works: a true copy of the selected file ends up on the
>>> server. Ain't that marvellous!
>>
>> Of course.  That has worked at least since HTML 4.01 became a W3C
>> Recommendation (1999).
> 
> Still: marvellous !

:)
 
> The key problem:
>>> using the form submit, the connection will be terminated (gracefully)
>>> after the upload.
> 
> As you have responded: it should not !

Evidentially it *will not*.  Not with a HTTP/1.1 client.

> And I have failed to find the cause.

I wonder how you get the idea that the connection would be terminated in the 
first place.  ISTM you are confusing HTTP with TCP.  HTTP is stateless; TCP 
is not.

> But I have found a workaround: in the <form> element I now specify a
> hidden <iframe> as target. This may be amateuristic but it works and after
> ten days of experimenting I will leave it at that. (I blame the server
> software.)

If the server software remains unchanged, that alone should not make a 
difference.

> Thank you very much for your suggestions, corrections and pointers.
> A small piece of feedback for future references: in your post
> <http://stackoverflow.com/a/8378918/855543>
> where you describe the file upload script principles, I think that the
> argument to the XMLHttpRequest().send() call should be terminated with a
> nlcr

(Probably you mean CRLF.)

> and closing boundary string.

You are correct (see RFC 2046, section 5.1.1).  Fixed.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#16360

"Thomas 'PointedEars' Lahn" wrote:
>
> I wonder how you get the idea that the connection would be terminated in 
> the
> first place.  ISTM you are confusing HTTP with TCP.  HTTP is stateless; 
> TCP
> is not.

I can trap exceptions thrown by the (Indy) server software. It reports 
"Connection Closed Gracefully". But an Indy expert responded with:
"No, it is not the server that is disconnecting.  It is the webbrowser that
is disconnecting.  That is what the EIdConnClosedGracefully exception means
- the *other party* disconnected on its end.  If you are getting the 
OnCommandGet/Post
event triggered, then the server is fully receiving the webbrowser's POST
request, but is then failing to send back its response to the webbrowser
because the webbrowser already disconnected its end of the connection.  It
did not wait long enough to receive the server's response.  Yoiu can use
a packet sniffer, such as Wireshark, to verify that.  Whoever is 
disconnecting
their end of the connection will have the FIN flag enabled on the TCP packet
is that closing their respective connection endpoint.  Given what you have
described so far, it would have to be the webbrowser that is sending the
FIN packet first."

But that doesn't make sense to me since IE8, FF and Chrome all show the same 
behaviour in this case. The fact that the <form target=..> solves the 
problem gives me the - gut-feel of a layman - idea that the server responds 
with an 'instruction' that leaves the browser no choice but to send that FIN 
flag. Since the 'instruction' now ends up in the target <iframe>, the 
browser has no need to do this and the connection remains established.
Tom 

[toc] | [prev] | [next] | [standalone]

#16382

"Tom de Neef" wrote:
>>
>> I wonder how you get the idea that the connection would be terminated in 
>> the
>> first place.  ISTM you are confusing HTTP with TCP.  HTTP is stateless; 
>> TCP
>> is not.
>
> I can trap exceptions thrown by the (Indy) server software. It reports 
> "Connection Closed Gracefully". But an Indy expert responded with:
> "No, it is not the server that is disconnecting.  It is the webbrowser 
> that
> is disconnecting.  That is what the EIdConnClosedGracefully exception 
> means
> - the *other party* disconnected on its end.  If you are getting the 
> OnCommandGet/Post
> event triggered, then the server is fully receiving the webbrowser's POST
> request, but is then failing to send back its response to the webbrowser
> because the webbrowser already disconnected its end of the connection.  It
> did not wait long enough to receive the server's response.  Yoiu can use
> a packet sniffer, such as Wireshark, to verify that.  Whoever is 
> disconnecting
> their end of the connection will have the FIN flag enabled on the TCP 
> packet
> is that closing their respective connection endpoint.  Given what you have
> described so far, it would have to be the webbrowser that is sending the
> FIN packet first."
>
> But that doesn't make sense to me since IE8, FF and Chrome all show the 
> same ****behaviour****1) in this case. The fact that the <form target=..> 
> solves the problem gives me the - gut-feel of a layman - idea that the 
> server responds with an 'instruction' that leaves the browser no choice 
> but to send that FIN flag. Since the 'instruction' now ends up in the 
> target <iframe>, the browser has no need to do this and the connection 
> remains established.

****behaviour**** is what it's all about: the browser clears the DOM. And 
with the <form target='some iframe'> added it doesn't. Closing the 
connection may be a red herring but it is the only traceable event that goes 
hand in hand with this behaviour.
Tom

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web