All Issues
24,993 verified issues
Problems with metadata-only requests and media MIME types
Thanks for the recent updates to this npm package. It's great, but I've been having some issues with the GMail API since the update to version 1.0.0. For at least the GMail API and possibly other apis as well, there is little support for metadata-only requests. Looking at the api code, 'isMedia' is always set for true in a function like users.drafts.create, as seen here: https://github.com/google/google-api-nodejs-client/blob/master/apis/gmail/v1.js#L65. Also, the /uploads URL is always used although some APIs support metadata-only requests with a different URL. A related issue is that it is impossible to correctly set the media MIME type for multipart uploads, which is all the code currently supports. The GMail users.drafts.create method, for example, requires a media MIME type of message/rfc822. If we make no effort to set this, we get the following API error: [code block] If, however, we add `resource: { mimeType: 'message/rfc822' }` to the options object, we get the following API error: [code block] This is because the gmail API does not have a mimeType field. Unfortunately, this is where the `createAPIRequest` function looks for setting the media MIME type. This seems to work for some APIs, such as drive, which actually do have a mimeType field, but it does not work for gmail. Thanks for any help you can provide in resolving this issue.
Don't reuse same-namespace connections
[code block] will create two connections moving forward.
reconnecting event gone?!
Why was the 'reconnecting' event removed? We used it to better control the reconnection timeouts and behavior. Also we now have no visibility into wether SocketIO is trying to reconnect or not. Please put it back.
Investigate supporting ES6/JSX
After many requests and some soul-searching, I've come around to believing that ESLint should optionally support JSX. My rationale is based on: 1. The growing popularity of React/JSX 2. The existence of Esprima-FB and estraverse-FB There is still the issue of escope not supporting es6 scoping rules and relying on estraverse directly, but that may be solvable. The way I'm envisioning this working is by allowing you to specify one of four JavaScript modes: 1. ECMAScript 3 2. ECMAScript 5 3. ECMAScript 6 4. JSX That means ECMAScript 6 support is separate from JSX support. You opt-in to JSX, you get whatever is in Esprima-FB vs. opting in to ES6, which should not support JSX syntax. This issue is to gather investigation data to determine how this can be achieved and what blockers might exist.
warn: client not handshaken client should reconnect
hello everyone.. i am new bee in socket.io and redis i have developing one chat application. but i have facing one problem, and i don't understand how to solve it. i have read many articles/blogs, but still i have don't find any clue/solution for the same. i have written following code: server-side : (app.js) [code block] <script src="http://XXX.XXX.X.XX/node_modules/socket.io-client/dist/socket.io.js" type="text/javascript"></script> $(document).ready(function () { chati = new Chat; chati.Connect($("#nickname").val(), $("#room").val()); return false; }); function Chat() { this.socket = null; this.Nickname = ""; this.Room = ""; [code block] // socket = io.connect('http://XXX.XXX.X.XX', { 'reconnect': true, transports: ['jsonp-polling', 'xhr-polling'] }); // socket = io.connect('http://XXX.XXX.X.XX', { 'connect timeout': 500, 'reconnect': true, 'reconnection delay': 500, 'reopen delay': 500, 'max reconnection attempts': 10 }); Nickname = nick; Room = room; // setInterval(function () { socket.emit("keep-alive", null) }, 20 \* 1000); [code block] --- when i am running my application, there is continually fires request from client side. when i have check the error log, i have find some warning message info: socket.io started warn: client not handshaken client should reconnect warn: client not handshaken client should reconnect warn: client not handshaken
Cannot call method 'writeHead' of undefined
I'm getting this in 0.8.6 I'm not sure which browser connected or caused the problem, this is just something I found in my err.log trying to figure out the reason for a crash. [code block] Back to 0.8.5 for now.
Deprecate app.param(fn)
This is a discussion for the deprecation of the `app.param(fn)` signature. To me, it solves a problem that doesn't exist. I would like to hear arguments to keep it around, hopefully with a use-case it actually solves, before it gets deprecated.
serv-static stops when loading many images from iphone mobile safari.
I use serv-static and put one html and some images which will load from the html. I connect this page from my iphone through LAN. Mobile safari loading progress bar is stop and some image file is not loaded. This issue doesn't occur in chrome on iOS, safari on Mac. First I think this is safari issue and is not express issue. But after my many investigation (eliminating application specific logic and search reproducible occurring condition), I think this is latter. I found that logic flow which close file reading stream before sending file completion. because of on-finish module implementation, if response.socket is null, it occur. I print log about response.socket in SendStream.stream() and in case image file not loaded, it was null. I tried to modify this code section. and issue is solved. I report detail of this issue at this repository. This can reproduce issue and run my patch. https://github.com/omochi/express-serv-static-issue I think that this stackoverflow is related to this issue. http://stackoverflow.com/questions/26352839/linkedin-dustjs-on-node-express-ios-safari
Empty rooms aren't deleted
I noticed a possible memory leak, so I tested by connecting to my server from about a dozen client webpages and repeatedly refreshing them. Memory usage increased with each refresh and never fell back to pre-refresh levels. Turns out the unique rooms that are created for new connections aren't getting deleted — they remain in the room list despite becoming empty upon refresh. Empty rooms are supposed to be destroyed automatically, so I don't know what's going on, but it might be why memory usage keeps rising. I tried explicitly deleting these rooms when a client disconnects. This removes them from the room list, but memory usage seems unaffected. I might be doing it wrong: [code block] Does this seem strange to anyone else? Is there another potential reason for the memory leak?
Switch to boot2docker as recommended way to run Docker on OS X
Probably blocked by https://github.com/steeve/boot2docker/issues/63, https://github.com/steeve/boot2docker/issues/84 and https://github.com/steeve/boot2docker/issues/85. See https://github.com/noplay/docker-osx/issues/17 and https://github.com/noplay/docker-osx/issues/29 for more background.
How to get client IP address?
How do I get a client's IP address? This does not seem to work: http://stackoverflow.com/questions/6458083/socket-io-get-clients-ip-address
any news about version 1.0?
I want to know if version 1.0 of socket.io is developping. I came across a critical memory issue in version 0.9, and the author say he will fix it in version 1.0. But the project looks like inactive recently. Anybody know any news about this?
0.7 doesn't work on Dotcloud, but 0.6.18 does.
I'm not sure what changed to cause this issue, but Socket.IO 0.7 isn't working on Dotcloud. They don't support WebSockets yet, so I've been using the XHR-Polling transport, but even that fails on 0.7--in fact; ALL transports fail on 0.7. The initial XHR request to acquire the session ID works fine, but once it starts trying to poll with it the requests just hang. It works fine on localhost, so I asked Dotcloud support about it and they are pointing the finger back at Socket.IO so I'm not sure what to do about that. Any ideas?
Alternative syntax for type assertions to allow XML-like syntax extensions
The current syntax for type assertions prevented the React team from adding TypeScript support to JSX. While E4X was a failure, XML-like syntax extensions is a good idea, which might make it into some next ECMAScript version. If it happens, it will be impossible to incorporate that syntax into TypeScript because of type assertions. (ported from http://typescript.codeplex.com/workitem/2608)
Sockets stay / remain established / connected on operation system but disconnected in socket.io
Hello, my problem : on .connection-event i count new connections, on disconnect-event i reduce the counter. internal it looks good - but on operation system the sockets stay / remain established and the amount is growing. (see my log downside) Please look at my 2nd posting - i guess i found out what's going on. Some ideas how to monitor it more detailed ? Can it be a problem between Node and Socket.io an one hand and the interaction on OS level ? At the moment i have to restart the node.js process every few hours ... Some ideas what to check ? (by the way we use {'sync disconnect on unload':true} on client side) Server: Debian 7.7 full updated, 4 GB, 4 CPU, KVM Server, express@4.10.6, Socket.io 1.2.1, Node.js v0.10.31 - could not finde bugs or issues related to this kind of problems. Yesterday i pachted Host Server up to 7.7 and i changed Node.js to v.0.10.33 - still growing amount of sockets on OS level Networksettings - i used Debian default and echo "1024 64000" > /proc/sys/net/ipv4/ip_local_port_range echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse echo "15" > /proc/sys/net/ipv4/tcp_fin_timeout Counted on Server/ OS level --- Fr 12. Dez 18:51:05 CET 2014 8 CLOSING 3 FIN_WAIT1 3 FIN_WAIT2 9 LAST_ACK 1 LISTEN 4 SYN_RECV 1308 TIME_WAIT 8009 VERBUNDEN/Established 9343 Counted internal in Socket.io/ Node.js --- root@aaaaaa:~tail -f /var/log/push.log Fri Dec 12 2014 18:46:33 GMT+0100 (CET) 2475 Fri Dec 12 2014 18:47:03 GMT+0100
Having a nested array call act as new "route".
Rather then writing the following [code block] I was hoping I could get the same effect with this [code block] However it's not supported. Thoughts? I know all about the `router`. My problem there is sharing the `params`.
ESLint 2.0.0 Wish List [$10]
As we are getting closer and closer to v1.0.0, it's time to start thinking about what a v2.0.0 would look like. Here are the things that have either come up recently or have been on my mind: - Autofix option - This has come up at least three times as a request. Originally I was pretty against it, but I'm starting to warm up to the idea. The idea is optionally fix certain types of issues instead of just reporting them. While this won't be possible for 100% of the rules, even a small percentage could make a big difference. - Autocreate config by looking at code - We need a way to make it easier to get started. Manually configuring over 100 rules is a painful process. It would be nice to be able to give ESLint a file and say "create me a config that matches the styles in this file". What other ideas do you have about big things we could tackle for 2.0.0? <bountysource-plugin> Did you help close this issue? Go claim the $10 bounty on Bountysource. </bountysource-plugin>
Create keys with expires
Hi, Is it poissible to send this Redis command with `ioredis` in just one function call? [code block]
TypeError: Failed to decode param ''
We have a nodejs app running on Heroku, and sometimes, without warning, all requests on a specific web dyno start to fail with a 400 Bad Request response. In the logs we can see entries like this: [code block] Restarting the app usually helps, but not always. Any idea what could be wrong? Our package.json dependencies: [code block] We haven't been able to reproduce or trigger this error in a test environment. Since this error is thrown by `decodeURIComponent`, we thought that we were missing some encoding. But after setting `LANG=en_US.UTF-8` the problem still occurs. We have also tried running the app on a local ubuntu vagrant image after removing all installed locales, but that didn't trigger the problem either.
[Initialization] Launch screen white flash
I just wondering if there is a good practice about LaunchScreen. The reason I'm asking this is, if one adds LaunchScreen, there is a white flash before react-native kicks in and load the app. Is there any way we can prevent this?