1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
<?php
$title = "Undefined? JavaScript Is Undefined.";
if (isset($early) && $early) {
return;
}
include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
?>
<p class="description">
So I've been working on a web app for my mom. Nothing too fancy, but
it's a store front for her glass art. It's an easy way for her to keep
track of inventory, update photos of her products, and for people to
shop and search and sort and browse through it. This backend is an HTTP
service written in Rust. The frontend is a Vue.js app. I've used Vue and
JavaScript many times before but I recently ran into an incredibly
strange bug. One that I would have hoped JavaScript would have some
guard against. But JavaScript is an undefined language.
</p>
<p>
I have a small component that uses a file input to collect an image from
the user. Then I append that file to a FormData and set that FormData as
a Fetch API request body. So I've got fetch API sending
multipart/form-data across the network to my backend. Awesome! The
backend is supposed to take each field of the request, turn the chunks
into a single stream of binary data, and write them out to an image.
Everything on the front seems like it's working great, it fires off the
request and throws no errors. But then the backend only sees a few bytes
of this multi-megabyte image. Not awesome! short chunks on the back-end.
The array of data in the API is less than ten bytes long, when this is a
many-kilobyte file I'm trying to upload.
</p>
<p>
At this point I'm relentlessly debugging, trying to find out what's
wrong with the API. Why is it truncating the request down to a few
bytes, where's the rest of the data? It took me forever to actually
inspect what those few bytes are and, lo and behold they're ASCII for
<code>undefined</code> The request happily stringified an
<code>undefined</code> object, instead of maybe throwing a null
reference or undefined error during request creation because that's just
what JavaScript does. <em>The linter didn't even catch it.</em>
</p>
<p>
You can see what the debugging logs looked like on the backend below.
Note that the <code>&data</code> is the field that spells out
"undefined". Also note that the file picker/FormData was constructed
alright because the key for the image name is correct.
</p>
<pre>
<code>
[src/handlers.rs:114] &field =
Field: application/octet-stream
boundary: ---------------------------175314640631070190963311652907
headers:
"content-disposition": "form-data; name=\"clu.jpg\""
[src/handlers.rs:119] &chunk = Ok(
b"undefined",
)
[src/handlers.rs:123] &data = [
117,
110,
100,
101,
102,
105,
110,
101,
100,
]
ImageWrite("The image format could not be determined")
</code>
</pre>
<p>
The <em>working</em> JS is here (it was late at night and I was so
donion rings I just fixed it and pushed it without saving the errors for
posterity):
</p>
<pre>
<code>
let file = event.target.files[0];
if (!file) {
return;
}
const fd = new FormData();
fd.append(file.name, file);
const response = await fetch("http://localhost:8000/photos", {
method: "POST",
body: fd
});
console.log(response);
</code>
</pre>
<p>
I've gotten frustrated by JS before but not like this. I don't know if
TypeScript would have solved this issue but writing in a language that
gets transpiled back into the language I'm trying to avoid doesn't seem
like the way forward. I'm looking forward to Web Assembly as a way of
using more type-safe languages in the browser.
</p>
|
