All Issues
24,993 verified issues
req.rawBody is no longer available (regression #34)
req.rawBody is no longer available in 1.5.1, I think it was the new "formidable" integration in connect/bodyParser that removed the feature. Is there another way to get the raw content after bodyParser parses the body?
Safari (Mac Only) crashes when using websocket
I am using the very basic example listed on the website, not sending or receiving any messages, just connecting. Connection is on 127.0.0.1:80 On connect Safari crashes with following: Process: Safari [11081] Path: /Applications/Safari.app/Contents/MacOS/Safari Identifier: com.apple.Safari Version: 5.0.5 (6533.21.1) Build Info: WebBrowser-75332101~1 Code Type: X86-64 (Native) Parent Process: launchd [238] Date/Time: 2011-04-23 02:40:30.463 -0400 OS Version: Mac OS X 10.6.7 (10J869) Report Version: 6 Interval Since Last Report: 140807 sec Crashes Since Last Report: 20 Per-App Interval Since Last Report: 36857 sec Per-App Crashes Since Last Report: 16 Anonymous UUID: 545FB01F-FF2E-4A16-9EFC-A8A538906A53 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 com.apple.CoreFoundation 0x00007fff87e11c00 CFArrayGetCount + 80 1 com.apple.WebCore 0x00007fff82a3150b WebCore::SocketStreamHandle::chooseProxyFromArray(__CFArray const_) + 43 2 com.apple.WebCore 0x00007fff82cc6088 WebCore::SocketStreamHandle::pacExecutionCallbackMainThread(void_) + 24 3 com.apple.JavaScriptCore 0x00007fff87bf6848 WTF::callOnMainThreadAndWait(void (_)(void_), void_) + 72 4 com.apple.WebCore
(node-gyp rebuild 2> builderror.log) || (exit 0)
[code block]
"Weird" utf-8 characters in POST body causing content-length mismatch
When I submit a POST request and the body contains characters like "å", the server responds with a 400 because the content-length didn't match. I'm guessing that the problem is that multiple byte utf-8 characters are being assumed to be only one byte long when they are counted. I'm not sure if this is a bug in express or connect or raw-body. Hopefully you can pass it along if it's not an express bug. This bug only seems to have appeared in express versions 3.4.2 and later. Here's the error message: [code block]
Routes execution order not honored
Hi! I have an app where routes look like this (simplified) [code block] After upgrading from 4.2.0 to 4.3.0 route '/stuff' stopped getting executed, though it is assigned first, it calls render and it should stop there. If you change the catch all route to '/*' it works again. I was wondering if it is an expected change (didn't notice in the History.md) and if it is going to change again. Currently it looks like defining a catch all basically kills your routing.
Expose mount paths to router
Right now, the only path information available in a router is its localized path. I want to be able to do things like build navigation and dynamic urls without having to hard code a value in my views. So if I mount "/outerapp", and inside i mount "/innerapp", I would expect to find some property in an object that would allow me to write "/outerapp/innerapp" in my views.
400 on malformed URIs
nicer than a 500
can't handle www.host
Suppose I wanted to proxy a site like cb2.com -- visiting this site, you'll see that it immediately redirects you to www.cb2.com. This is a problem, as I'm unable to proxy the content of the site as my browser begins accessing www.cb2.com directly instead of continuing to proxy via localhost. I've tried simply setting the host to be www.cb2.com instead of cb2.com, but it fails. No errors, the browser just waits. [code block]
keepalive requests are slow
see https://github.com/nodejitsu/node-http-proxy/issues/477#issuecomment-24574204
consider removing app.configure()
pros: - you can use `app.settings.env` - less misleading since people often think it's required - middleware config in separate function calls is difficult to manage - it's unclear that the functions are executed immediately cons: - uglier - less declarative todo: - add it to list of changes - update examples - remove internal use of .configure()
Download zip file
I am looking for some help with my current issue. I am trying to download a zip file using `res.download`. My code for downloading the file is very simple [code block] bulk-output.zip is file that sits in the root of my repository. When I download this file from the browser I get the following error when unzipping the file. Any thoughts on what is wrong here? I imagine the problem is on my end but I am unable to nail down the problem.
Twilio.sendMessage, price in response data is null
I used Twilio.sendMessage to send SMS: [code block] Here is the sample of the `responseData`: (some fields are masked) [code block] and the field `price` become null
Express 4.0
Backwards incompatible changes. Woo! - [x] Remove express(1) #1820 - [x] Remove app.configure #936 - [x] Change req.params to an object #1835 - [x] Remove/fix res.location() relative paths #1804 - [x] Remove res.locals(obj) #1833 #1908 - [x] Make app[VERB] each its own middleware #1909 - [x] Remove dependency on connect - [x] Fix this error in node 0.11: - [ ] ~~Remove app inheritance/revisit mounting `app` and what this means. Right now it is too confusing and not documented. #1843~~ - [ ] ~~Lazy cookies #1139~~ - [ ] ~~View middleware/module (allows for view engine as middleware)~~
Memory issue with getters since node 0.9.4
Hi, we was fighting with high rss consumption last days since we switched to node 0.10.12. We finally found out where the problem actually is. Its probably not directly a mongoose issue, but I think mongoose users might want to know about this and if we get a mongoose free reproducible code, then we can create an issue on node or v8 tracker. We tracked down the issue you can reproduce with the code from gist to this particular part: [code block] Behaviour When you start to send requests, memory usage gets higher and higher until OS limit is reached, gc is not able to cleanup in this specific case provided in the example. Hotfix If you use gc_global option for v8 "node --gc_global mongoose-test.js" which will reenable periodical garbage collector, the issue will not be reproducible any more. Since when https://github.com/joyent/node/commit/d607d856afc744b1e6bc42cdb9b67b6c4e7e4876 This commit is the point where the issue comes in play. In my opinion incremental gc has a bug. This commit is relased with node 0.9.4, the issue is not reproducible in all versions below and it is reproducible in all version higher. How to reproduce 1. Download 2 files from this gist https://gist.github.com/kof/5884355 2. start mongod 3. $ node mongoose-test.js 4. $ for i in {1..500}; do curl http://localhost:8888/; done
Add support for the per-frame DEFLATE extension
Any plans to add support for per-frame DEFLATE: http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-06 Some basic tests suggest I could reduce the size of my message frames to just 12% of their original size. That would help a lot with bandwidth usage. Thanks!
WebSockets lag behind when sending bursts of image frames
Hello guys First of all, socket.io works like a charm with latest nginx addition 1.3.13 for native websockets. My app works well except ... the performance! I'm sending compressed jpg images from client to server at 13 fps through web sockets via socket.io. In Chromium I see data frames for each emit() are about 20KB, meaning 13 x 20KB = 260 KB of data is sent each second. After 10 seconds the client begins to lag behind. Now I wonder if this is a performance issue with socket.io or an issue with my code? Maybe I need to configure socket.io + nginx better? Or should I send the image frames less frequently in packets or compress these? Any suggestions, any hints are welcome. Michael
Deprecate res.send(status, body) format
This is a discussion regarding the possibility of deprecating `res.send(status, body)` and other methods (`json`, `jsonp` to name some) that do the same thing, where there is an optional first status argument. Specifically, deprecating the optional `status` as a first argument thing. /cc @defunctzombie
Uploading files to S3 from EC2 instances fails on some instance types
We have a very strange problem. We are uploading large (10M) files from an EC2 instance to an S3 bucket in the same region. We use `aws s3 cp` for the upload and instance roles for authentication. If we use an `m1.small` EC2 instance the upload works fine. But if we increase the instance size (we have tried `m1.large` and `m3.large`) the upload fails. Here is the error we get: [code block] This is completely reproducible -- we have never had such a upload succeed after tens of attempts. We have never seen the problem on an `m1.small` instance in hundreds of attempts. We ran into this problem with 10M files. We have found that it is reproducible down to about 1M. Much less than this and it works fine every time. Any ideas about what is going on would be much appreciated.
can't install socket.io on windows 7
tried npm install socket.io I have VS 2012 installed get the following errors: C:\Program Files\nodejs\node_modules\socket.io\node_modules\socket.io-client\no de_modules\ws\build\bufferutil.vcxproj(18,3): error MSB4019: The imported proje ct "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. C:\Program Files\nodejs\node_modules\socket.io\node_modules\socket.io-client\no de_modules\ws\build\validation.vcxproj(18,3): error MSB4019: The imported proje ct "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. tried loading the project into VS and building, but get errors there tried setting condition exists in on import of Microsoft.Cpp.Default.props, but build errors persisted. Is there any way around all these errors?
Client handshake returns error message "Transport unknown"
I was trying to initialize a handshake, following the specs I've found at LearnBoost/socket.io-spec. Sometime I found that it has to be done with a `POST` request, sometime with `GET`. I've tried both of them and they both returned the same error: [code block] > { > "code": 0, > "message": "Transport unknown" > }