Develop Reference

Azure Storage Javascript library "createBlobServiceWithSas" throws error: Refused to set unsafe header "user-agent"

Using the Azure Storage JS Client library to upload an image throws an error: "Refused to set unsafe header "user-agent""
All requests in the network tab are 200 or 201, it appears like the xhr requests are working. Is it possible to not set this header or filter it out before the post call? I would like to avoid this error in the console.
https://github.com/Azure/azure-storage-node#azure-storage-javascript-client-library-for-browsers

Have tested the sample azurestoragejs-2.9.100-preview in link you mentioned, it causes no error on my side(both Chrome and Firefox).
Open azure-storage.blob.js lib file, search variable var unsafeHeaders and check whether user-agent is in its list. I saw it on my side and reproduce your problem after deleting it. So it might be missing in your file.
If your lib is unbroken, you can ignore this "error" as nothing goes wrong and it's all implemented by storage lib and browser.
Explanation:
When http request executes, method in this lib will make sure headers in unsafeHeaders list won't be set by xhr. If not, browsers will throw warnings as you have seen, because it's a requirement of xhr standard.
See remarks in this lib.
This check is not necessary, but it prevents warnings from browsers about setting unsafe headers.To be honest I'm not entirely sure hiding these warnings is a good thing, but http-browserify did it, so I will too.
Everyting does work on your side may have proved the check is not necessary. Also in xhr standard, user-agent is no more an unsafe header, but browser doesn't catch up.

Firebase Rest API status code 18

I'm performing a multi-path update to Firebase that results in receiving the undocumented error code 18.
I can perform the multi-path update in smaller chunks, and I receive a successful 200, but when it is all in one, the request fails. Also, I know the request is formed correctly as I've made sure to beware the multi-path update pitfall explained here.
So, what's the deal?

The deal is, quite unexpectedly, that I have the "debug" claim set to true in the Authentication token.
Because the multi-path update tests the security rules at each supplied path, and the “x-firebase-auth-debug” response header contains the results of each security rule, that can lead to a very large header. So large that it causes Firebase to return status code 18, which is the cURL Partial File error.
Now, apparently there is no actual header-size limit defined by HTTP, but most web servers impose some sort of limit for size of headers in and out. If the size is too large, servers should return a “413 Entity Too large”, which Firebase is not doing and is the cause of the issue (I believe).
Removing the "debug" claim from the token and performing the exact same multi-path update results in success.
EDIT:
On other occasions, I've received other cURL errors rather than the expected HTTP response codes - is there a reason that these remain undocumented? (I guess it could be the server that I'm sending requests from, so I'll check there and update later, but I figured I'd ask just in case...)

Why are my custom headers giving an "Adapter operation failed" error?

Aloha! Today, I'm trying to add custom headers to each request to my backend.
Playing with my DS.RESTAdapter, I already tried:
The 3 headers: solutions suggested in the official guide.
The 2 ajax: approaches proposed around there.
And 2 jQuery workarounds (based on $.ajaxPrefilter and $.ajaxSetup) that I found there.
Until now, my only result was this very obscure "Adapter operation failed" error:
{
details: "",
status: 0,
title: "The backend responded with an error"
}
I know that:
My backend behaves well and returns a 200 status (I tested sending the request via cURL).
Strangely, removing my adapter's host setting allows the request to be sent, but obviously at the wrong URL.
My problem is not a CSP issue as I'm currently running both backend & frontend locally.
According to my debugging and to my Network Inspector tab, the AJAX request is just never sent (XHR.readyStatus is stuck at 0).
Has somebody already faced this?
Any help would be really lovely!
Ember 1.13.11
Ember Data 1.13.15
jQuery 1.11.3
EDIT: Magic minimal app reproducing the bug is out here!
Hope you'll enjoy it! And because I love you so much, I also offered a demo API endpoint on my server. Details in the FM!
BONUS! Do you know what is the coolest thing to put in a clipboard?
git clone https://github.com/imbrou/ember-data-headers-demo.git
Yeeeeeeha! (-:

Usually "Adapter operation failed" error occurs because your application is having problems connecting to the backend, usually DS.RESTAdapter is not correctly setup, make sure your host and namespace are correct.
Example:
export default DS.RESTAdapter.extend({
host: 'http://193.137.170.210:8080',
namespace: '/api'
});

Solved !
My backend was not sending the correct CORS headers.
The tricky thing is that for an unknown reason, my version of Firefox (Developer Edition...) didn't display the failing OPTIONS request in my Network Inspector at the point of my debugging. I thus had no debugging information at all there.
I could only observe the failing preflight using... Wireshark !
It may have been a bug solved in a Christmas update, as I can't reproduce it today. Too bad...
Anyway, in desperation, I linked 3 screenshots:
No-preflight example: no backend security (no "authorization" token).
Working example: the "authorization" header is requested by client, and allowed by server in the response during the preflight.
Failing example: the "authorization" header is requested by the client, BUT not allowed by the server.
Hope it helps, thanks #Vítor for your support !

Network Error 12152: WebSockets in Edge and IE 11

I have a site using websockets secure (WSS) and works very well in chrome.
Testing in IE and Edge also works however in the browser console I get Network Error 12152 which will also trigger the websocket.addEventListener("error",function(){}) if implemented.
Everything actually works I just get this error which doesnt seem to break anything.
Error is triggered When socket is closed from Browser Side
Headers in EDGE
More Info: Example of the code I use
//connect via wss then
ws.addEventListener("error",function(event){ // this hits when Socket is closed})
ws.addEventListener("open",function(){
ws.addEventListener("message",function(event){
//do stuff
ws.Close()
})
})
To Confirm the problem further
I went to https://www.websocket.org/echo.html in edge the site which has the ability to test websocket connections. I made it connect to my server. which opens the connection without a problem. However in just the same way I have been getting problems with my code. This site also throws an error when I click the disconnect button. See Image Below. Is this a bug in IE/Edge?
My Server isnt disconnecting correctly?
I use the above site with the default destination (Their websocket server) and not mine. There are no errors. But when connecting to mine on disconnect there are errors.
What could be the problem?
Thanks

Looking at the Microsoft KB article you are not givng back the expected response/headers on connection setup
From the microsoft knowledge base
12152 ERROR_HTTP_INVALID_SERVER_RESPONSE
The server response could not be parsed.
From the developper docs of mozilla if you look at the Server Handshake Response part
When it gets this request, the server should send a pretty odd-looking (but still HTTP) response that looks like this (remember each header ends with \r\n and put an extra \r\n after the last one):
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
So, I suggest you check your headers and see which responses you are sending on the handshake, so you keep in line with protocols.

I have fixed the same error in IE browsers. Check the capitalization of the first letter of websocket.
Non IE browser:
Upgrade: **w**ebsocket
IE browser:
Upgrade: **W**ebsocket

Handling unsuccessful websocket upgrade requests in Javascript Client

I want to have a javascript client process get the HTTP status code that a server is returning when the client makes a websocket upgrade request and that request is unsuccessful.
I have my server returning HTTP 400 to indicate that a websocket upgrade is unsuccessful.
I am using Google Chrome and when i open the developer console I can see the following message:
WebSocket connection to 'wss://' failed: Error during WebSocket handshake: Unexpected response code: 400
However, the onerror handler does not contain this message, it receives a 1006 error but does not indicate that the closure occured as a result of getting HTTP 400.
How does a javascript developer handle handshake errors? I would like to provide the client with an informative message when they get a handshake error.
I have put the websocket error below, it does not seem to contain anything that I can use to indicate that this error is a result of a websocket handshake error.
Websocket Error: {"path":{"length":0},"cancelBubble":false,"returnValue":true,"srcElement":{"binaryType":"blob","protocol":"","extensions":"","bufferedAmount":0,"readyState":3,"url":"wss://<my address>","URL":"wss://<my address>"},"defaultPrevented":false,"timeStamp":1417828938039,"cancelable":false,"bubbles":false,"eventPhase":2,"currentTarget":{"binaryType":"blob","protocol":"","extensions":"","bufferedAmount":0,"readyState":3,"url":"wss://<my address>","URL":"wss://<my address>"},"target":{"binaryType":"blob","protocol":"","extensions":"","bufferedAmount":0,"readyState":3,"url":"wss://<my address>","URL":"wss://<my address>"},"type":"error"}

I am afraid there is no way from Javascript to know the HTTP status code of the negotiation.
There are defined closing codes, and 1006 only means that the connection is closed abruptly, but the protocol even allows to close the connection without providing a reason. That, together with the readyState API, are the only tools you have to diagnosed the reason of the problem.