Cannot upload source maps

I am trying to enable client side error logging using RUM.

I have used these pages to guide me

I've tried it both in Postman and Javascript and I always get the following response:

"error": "Content-Type header [multipart/form-data; boundary=--------------------------037463214125015102208974] is not supported",
"status": 406

The boundary number changes on each request.
What is going on here?

Elasticsearch version is 6.5.4


That sounds like the multipart/form-data is not correct; I don't know how Postman sends the request behind the scenes, but with curl you can do it like so:

curl -v -X POST -F service_name="test-service" -F service_version="1.0" -F bundle_filepath="http://localhost/static/js/bundle.js" -F

Do you get the same error if you try it like that?


Yes it is the same; Here is the output

Jordans-MacBook-Pro:example jordan$ ls
Jordans-MacBook-Pro:example jordan$ curl -v -X POST https://[redacted] -F service_name="test-service" -F service_version="1.0" -F bundle_filepath="http://localhost/static/js/bundle.js" -F
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying [redacted]...
* Connected to [redacted] ([redacted]) port 9243 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /Users/jordan/anaconda/ssl/cacert.pem
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject:
* start date: Jun 4 00:00:00 2018 GMT
* expire date: Jul 4 12:00:00 2019 GMT
* subjectAltName: host "[redacted]" matched cert's ""
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
POST /assets/v1/sourcemaps HTTP/1.1
Host: [redacted]
User-Agent: curl/7.52.1
Accept: /
Content-Length: 2549222
Expect: 100-continue
Content-Type: multipart/form-data; boundary=------------------------390df24a65c17fdd

< HTTP/1.1 100 Continue
< HTTP/1.1 406 Not Acceptable
< Content-Type: application/json; charset=UTF-8
< Date: Wed, 09 Jan 2019 11:42:55 GMT
< Server: fp/4b1cb7
< X-Found-Handling-Cluster: [redacted]
< X-Found-Handling-Instance: instance-0000000004
< X-Found-Handling-Server:
< Content-Length: 134
< Connection: keep-alive
* HTTP error before end of send, stop sending
* Curl_http_done: called premature == 0
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
{"error":"Content-Type header [multipart/form-data; boundary=------------------------390df24a65c17fdd] is not supported","status":406}


I unfortunately can't reproduce it. Just to double check, you are also using Apm Server 6.5 and not setting the content type header at any moment, right? And you are POSTing that to the APM Server directly and not to any proxy.

Could be the case that the sourcemap is not correctly generated? If you wget this one and POST it in the same way, does it work?

Thanks, your last comment about APM Server made me think about what I did - problem is solved.
I was sending the request to elastic search instead of the apm :confused:
The same request to elastic search will attempt to create an index

Glad to hear you got it, have a good day.


This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.