echo: x-socket-id header default causing issues.

Why is the X-Socket-Id set per default?

This causes a shitload of problems with most API’s and it would be more beneficial to add it whenever you need to call a socket endpoint, rather than to remove it when it causes problems.

The Github API for example does not allow it in their preflight response. For Axios I have to do this all over the place now:

axios.get('user/repos', {
    transformRequest: [function (data, headers) {
        delete headers['X-Socket-Id'];
        return data;
    }]
})

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 5
Comments: 19 (1 by maintainers)

Most upvoted comments

Temporary workaround is to just unset this header like this:

$.ajaxSetup({
  beforeSend: function() {}
})

After creating new Echo’s instance.

ImJustToNy on Dec 19, 2017

i have same issue using axios

sir-guevara on Jan 31, 2019

For example I am building something with React, I’m not using jQuery, I use fetch for API requests.

And I’m using axios, which is a default/external lib. they shouldn’t break how it works.

As also mentioned above; you don’t always have control over external libs. astonished this issue has been open for this long already without any indication of something going to happen.

jlsjonas on Sep 27, 2018

I have same issue - L5 + UploadCare widget @latest + Echo @latest

As result UploadCare don’t work

Failed to load https://upload.uploadcare.com/base/?jsonerrors=1: Request header field X-Socket-Id is not allowed by Access-Control-Allow-Headers in preflight response.

I can’t unset X-Socket-Id from all 3rd party libs.

tgosp on Oct 19, 2017

A good option to this would be using the native function fetch() to make requests in Javascript.

It solved my problem.

bruno-silva5 on Feb 3, 2022

@driesvints Actually I believe the issue is not just it being opt-out/in.

Echo should not break usage of an external library.

but the right way to do this is to wrap external requests in a separate API abstraction and remove that particular header from the request before sending rather than doing it “globally”.

That’s exactly what Laravel should be doing; instead of expecting 3th party libs to do this. A lot of optimizers will check if a lib already exists globally and not include it again (which is likely why the uploadcare lib that @ImJustToNy uses broke). I understand the reasons behind it but if the override is preserved it should at least check for a matching hostname before adding headers that break CORS configurations. (just my 2 cents)

jlsjonas on Nov 9, 2018

I think we may provide a config option for this. I think the reason why the PR was closed was because it’s changed to opt-in. If we’d have a new PR which was opt-out then I think it could be accepted.

driesvints on Oct 31, 2018

@rohan-deshpande, yeah, you’re right but I think echo’s way of forcing it to user is incorrect. In my particular example, external lib (uploadcare) wasn’t able to send request to it’s CDN because of this header which was injected into jQuery’s ajax method that this library uses. Took me a little while figuring what’s going on. In my opinion it should be turned off by default.

ImJustToNy on Aug 19, 2018