I want to know what is the format if the http request with content-type form-data and Transfer-Encoding chunked so i can decode it and extract the information from it.
I have considered two potential scenarios, but I am uncertain as to which one is the most appropriate.
POST /upload HTTP/1.1
Host: localhost
Content-Type: multipart/form-data; boundary=--1234
Transfer-Encoding: chunked
----1234
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg
f0
(f0 bytes of the image data)
ff
(ff bytes of the image data)
0
----1234--
And the second scenario is:
POST /upload HTTP/1.1
Host: localhost
Content-Type: multipart/form-data; boundary=--1234
Transfer-Encoding: chunked
5
----1
3
234
5C
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg
f0
(f0 bytes of the image data)
ff
(ff bytes of the image data)
a
----1234--
0
in the last scenario the whole body is chunked included the boundary.
Related
In making a request to my website with curl and HTTP 1.1, I see my keep-alive connection header explicitly:
$ curl https://website.com/ -i
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 2
Connection: keep-alive
But with Chrome's developer tool and HTTP 2 the header is missing:
Content-Type: text/html; charset=utf-8
Content-Length: 2
In HTTP 2 is it normal that the connection header is not sent (and why)?
Yes, this is normal and specified by the HTTP/2 RFC.
I am facing a problem in golang http server where client is sending a http request with invalid parameters in header. The request parameters are as follows:
GET /a-53-qf21489190x38856_2/yy HTTP/1.1
Host: xxx.xxx.xxx.xxx:80
User-Agent: mot-w845
Connection: Keep-Alive
Profile: http://10.213.2.68
X-MDN9035445271
accept: application/vnd.wap.mms-message
accept-language: en
accept-charset: US-ASCII, ISO-8859-1, UTF-8
HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8
Connection: close
Here X-MDN9035445271 doesn't contain colon (:) separator, because of this server is returning bad request. Is there any way to ignore such kind of header and process the request normally.
I am trying to make a HTTP POST request but it keeps failing. Is anything wrong with the request? Is it missing anything or is there anything that should be removed?
POST /add_file HTTP/1.1
Content-Encoding: gzip
Content-Type: multipart/form-data; charset=utf-8; boundary=463762444806
Host: BuzWebServer
--463762444806
Content-Disposition: form-data; name="File"; filename="demo.txt"
Content-Type: text/plain
demo text blah blah blah
--463762444806--
A very important header was missing, the Content-Length header
There's an HTTP request to the IceCast 2.3.2-kh29 server MP3 stream http://*:*/.mp3 and response (some data are **ed):
GET /*.mp3 HTTP/1.1
Host: ***:*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
HTTP/1.0 200 OK
Content-Type: audio/mpeg
icy-br: 192
ice-audio-info: bitrate=192;samplerate=44100;channels=2
icy-description: MP3 192 Kbps
icy-genre: *
icy-name: *
icy-pub: 1
icy-url: http://*
Server: Icecast 2.3.2-kh29
Cache-Control: no-cache
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
The Content-Length is not specified in the response. Also keep-alive is missing, despite the request. Is it normal situation? The protocol specifies that Content-Length must be in this case. The stream starts playing. Can be somehow that not all headers are shown in LiveHTTPHeaders this way? Or the stream is a special case, when used some sort of artificial made Content-Length?
HTTP 1.0 does not require that a content length is specified. SHOUTcast/Icecast servers will not specify the content length because the streams are live and there is no pre-determined length.
This question already has answers here:
How does HTTP file upload work?
(5 answers)
Closed 8 years ago.
I'm working on an iPhone app that makes a multipart HTTP request with multiple image files.
It looks like what's happening, on the server side, is that one of the images is getting parsed properly, but the other two files are not.
Can anybody post a sample HTTP multipart request that contains multiple image files?
Well, note that the request contains binary data, so I'm not posting the request as such - instead, I've converted every non-printable-ascii character into a dot (".").
POST /cgi-bin/qtest HTTP/1.1
Host: aram
User-Agent: Mozilla/5.0 Gecko/2009042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://aram/~martind/banner.htm
Content-Type: multipart/form-data; boundary=2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0f
Content-Length: 514
--2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0f
Content-Disposition: form-data; name="datafile1"; filename="r.gif"
Content-Type: image/gif
GIF87a.............,...........D..;
--2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0f
Content-Disposition: form-data; name="datafile2"; filename="g.gif"
Content-Type: image/gif
GIF87a.............,...........D..;
--2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0f
Content-Disposition: form-data; name="datafile3"; filename="b.gif"
Content-Type: image/gif
GIF87a.............,...........D..;
--2a8ae6ad-f4ad-4d9a-a92c-6d217011fe0f--
Note that every line (including the last one) is terminated by a \r\n sequence.
EDIT: I am maintaining a similar, but more in-depth answer at: https://stackoverflow.com/a/28380690/895245
To see exactly what is happening, use nc -l and a user agent like a browser or cURL.
Save the form to an .html file:
<form action="http://localhost:8000" method="post" enctype="multipart/form-data">
<p><input type="text" name="text" value="text default">
<p><input type="file" name="file1">
<p><input type="file" name="file2">
<p><button type="submit">Submit</button>
</form>
Create files to upload:
echo 'Content of a.txt.' > a.txt
echo '<!DOCTYPE html><title>Content of a.html.</title>' > a.html
Run:
nc -l localhost 8000
Open the HTML on your browser, select the files and click on submit and check the terminal.
nc prints the request received. Firefox sent:
POST / HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: __atuvc=34%7C7; permanent=0; _gitlab_session=226ad8a0be43681acf38c2fab9497240; __profilin=p%3Dt; request_method=GET
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------9051914041544843365972754266
Content-Length: 554
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="text"
text default
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="file1"; filename="a.txt"
Content-Type: text/plain
Content of a.txt.
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="file2"; filename="a.html"
Content-Type: text/html
<!DOCTYPE html><title>Content of a.html.</title>
-----------------------------9051914041544843365972754266--
Aternativelly, cURL should send the same POST request as your a browser form:
nc -l localhost 8000
curl -F "text=default" -F "file1=#a.txt" -F "file2=#a.html" localhost:8000
You can do multiple tests with:
while true; do printf '' | nc -l localhost 8000; done