AltME groups: search

Gabriele: #3402 is an outstanding bug when using /CUSTOM refinement. 
 An example is submitting a  form over http using REBOL. You need 
to specify both HEADER and POST. For example:

   read/custom url [HEADER [Content-Type: {multipart/form-data; boundary=---xyz} 
   ] POST {blah}]

The problem is that the handling of POST *overwrites* the Content-Type 
and Referer even though they may have been specified in HEADER. This 
logic bug is within the create-request function of Open in HTTP scheme.

read/custom url [POST {blah} [Content-Type: {multipart/form-data; 
boundary=---xyz} ]]

A second source of information are the environment-vars passed by 
the server. They are in system/options/cgi.  'decode-multipart-form 
needs system/options/cgi/content-type. There youself can look what 
the datas are too. if it is "multipart/form-data", use 'decode-multipart-form. 
i don't know the other types, just send a script a form and dump 
it.

Hello, I need to send multipart/form-data to a server for uploading 
a file from the console. I've been googling and searching the script 
archive, to no avail. Can anyone help?

Thanks for the help. The recipe from the rebol cookbook show you 
how to upload a file provided the server runs a rebol script too. 
The server I'm uploading a file to doesn't. It expects multipart/form-data. 
Maybe the %cgi.r by Cal Dixon provides a solution. I'll investigate 
further. More hints will be appreciated, as well...

In other words, the rebol script has to send values to a form on 
the server issuing something like that in the header: Content-Type: 
multipart/form-data; boundary=----------6l5Xq9lJYPaaypknAH8Des etc. 
Surely someone has done this before (I hope)...

I played with Oldes script a bit, didn't get far. I think there's 
no other option than follow Graham's advice and delve in the http 
scheme. I had hoped to find something in the script archive, oh well... 
I saw that even in the Ruby and Python community there's some confusion 
on how to achieve multipart form submissions with CGI. (Python default 
http library also uses  "application/x-www-form-urlencoded" and not 
""multipart/form-data", but there's a library called HTTPFileUploader 
that does the job). Last time I tried to hack the http scheme I wasn't 
so succesful. This time, if I need help, I'll ask for help.

Is there any script for multipart/form-data upload from Rebol to 
server?

I think you can just do that using post with a Content-type: multipart/form-data 
and send the boundary, and post size

The web and soap/http are in a sense REST applications (REST is just 
WS over HTTP) though both use a limited subset of REST arguments 
and have to work around as such.


The web is limited (by the HTML spec) to the verbs 'get and 'post, 
and post content types of 'application/x-www-form-urlencoded (default) 
or 'multipart/form-data (used to upload files).  For the most part, 
the web is RESTful as we usually only want to 'get resources.  However, 
other operations typically violate REST principles, as all other 
resource actions (create, update, delete) have to squeeze through 
the get/post/url-encode/multipart pipe.  The Rebol HTTP protocol 
as standard is designed to mimic this and requires patching to move 
beyond get/post/url-endode (even for multipart)


SOAP as I understand it, when using HTTP only uses 'post - the post 
content contains the actual request.  Where it varies from the web 
(and Rebol HTTP) is the need for the 'text/xml content type.


REST itself is limited only by HTTP.  It uses theoretically limitless 
HTTP (v1.1) verbs (though most common patterns use 'get, 'put, 'post 
and 'delete).  It uses any encoding.  It uses HTTP headers as parameters 
(eg. the 'Accept header specifies the desired return type).  Therefore, 
any HTTP protocol designed for REST will accomodate SOAP requests.

<form action="show.rsp" method="POST" enctype="multipart/form-data">
	<input type="file" name="ufile" size="16" />
	<input type="submit" name="usubmit" value="upload" />
</form>

I found a possible bug in RSP yesterday: When RSP gets the values 
passed to it as get query parameters, it removes url-encoded html 
tags and comments from the values. This is not correct with values 
that come from a textarea, or probably other values as well. I haven't 
tested with multipart/form-data encoding yet.


This might be a setting change rather than a bug in RSP, but if so 
then show.rsp should be changed to not strip tags from values and 
then html-encode the values when shown.

Check if your FORM tags are using enctype="multipart/form-data" to 
indicate proper encoding for file uploading.

Here's the test source:
<!doctype html>
<html><body>

<form action="blah.rsp" method="POST" enctype="multipart/form-data">
<input type="file" name="ufile" size="16" />
<input type="submit" name="usubmit" value="upload" />
</form>
</body></html>

And here's the test target:
<%=mold request/content%>


I get the same error with show.rsp, so I went with something simpler.

Same error after upgrading Chromium, here's the verbose 5 log of 
the request:


3/4-01:38:00.891-[HTTPd] ================== NEW REQUEST ==================

3/4-01:38:01.531-[HTTPd] Request Line=>POST /ecg/blah.rsp HTTP/1.1

3/4-01:38:02.109-[HTTPd] Trying phase method-support ( mod-static 
)

3/4-01:38:02.828-[HTTPd] Trying phase url-translate ( mod-static 
)
3/4-01:38:03.062-[uniserve] Calling >on-received< with {^M
Host: localhost:8080^M
Connection: keep-alive^M
Us}
3/4-01:38:03.547-[HTTPd] Request Headers=>
Host: localhost:8080
Connection: keep-alive

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 
(KHTML, like Gecko) Chrome/2.0.173.0 Safari/530.5
Referer: http://localhost:8080/ecg/blah.html
Content-Length: 153149
Cache-Control: max-age=0
Origin: http://localhost:8080

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryEv3SZArZWdjyznJZ

Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,bzip2,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3



3/4-01:38:03.797-[HTTPd] Trying phase url-to-filename ( mod-alias 
)
3/4-01:38:04.031-[HTTPd] => request processed
3/4-01:38:04.766-[HTTPd] Trying phase url-to-filename ( mod-rsp )
3/4-01:38:05-[HTTPd] => request processed

3/4-01:38:05.469-[HTTPd] Trying phase url-to-filename ( mod-internal 
)

3/4-01:38:05.719-[HTTPd] Trying phase url-to-filename ( mod-static 
)
3/4-01:38:05.969-[HTTPd] => request processed

3/4-01:38:06.453-[uniserve] >> Port: 3789, low-level reading: 17520

3/4-01:38:06.703-[uniserve] >> Port: 3789, low-level reading: 17520

3/4-01:38:06.953-[uniserve] >> Port: 3789, low-level reading: 17520

3/4-01:38:07.437-[uniserve] >> Port: 3789, low-level reading: 17520

3/4-01:38:07.906-[uniserve] >> Port: 3789, low-level reading: 19980

3/4-01:38:08.391-[uniserve] Calling >on-received< with "------WebKitFormBoundaryEv3SZArZWdjyznJZ^M^/Content-"

3/4-01:38:08.875-[uniserve] >> Port: 3789, low-level reading: 16680

3/4-01:38:09.344-[uniserve] >> Port: 3789, low-level reading: 17520

3/4-01:38:09.844-[uniserve] >> Port: 3789, low-level reading: 17520

3/4-01:38:10.312-[uniserve] >> Port: 3789, low-level reading: 1149

3/4-01:38:10.797-[uniserve] Calling >on-received< with {037.17923" 
"4429 SUNNYSLOPE RD SW" "Port Orchard" }

3/4-01:38:11.266-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'insert
    arg2: 'series
    arg3: [series! port! bitset!]
    near: [insert/part tmp/port s skip e]
    where: 'process-bounded-content
] !
3/4-01:38:11.734-[uniserve] Port closed : 127.0.0.1

While testing now, I've noticed a few issue with send-email/attach: 
header and multipart/form-data encoding. I'll fix them tonight, need 
to go now.

SVN r21 :


FEAT: log verbosity handling refactored, now more consistent across 
modules

FIX: email.r lib doesn't interfere anymore with other Rebol built-in 
schemes
FIX: bug in multipart/form-data decoding in RSP.r
FIX: email.rsp demo script now handles attached file correctly

I assumed it only put file data there and still captured the non 
file data into request/content

 => it requires to send data using "multipart/form-data" encoding.

Binary support / upload: these are 2 different things. Uploading 
files (access to local filesystem) still requires FORM with multipart/form-data 
encoding.