[NodeJS] Vreemde data na opvragen ZeroMQ request

[AW_Bos]

Ik ben zojuist aan het spelen met NodeJS waarmee ik realtime treinposities wil ophalen.
Het lijkt erg goed te werken, en ik krijg van de server al de nodige data via de zmq-socket binnen:

code:

var http = require('http');
var zmq = require('zmq');
var sock = zmq.socket('sub');
zlib = require("zlib");
var request = require('request');

var headers = {
      'Accept-Encoding': 'gzip'
    };

    request({url:'http://localhost:8082/', 'headers': headers})
        .pipe(zlib.createGunzip()) // unzip
        .pipe(process.stdout); // do whatever you want with the stream

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'}); 
    sock.connect('tcp://example.org:1337');
    sock.subscribe('/RIG/NStreinpositiesInterface5');
    console.log('Subscriber connected');
 
    sock.on('message', function(topic, message) {
    res.end(message);
    console.log('received a message related to:', topic, 'containing message:', message);
    });


}).listen(8082);

Als ik nu naar poortje 8082 luister krijg ik allemaal sloten aan 'rubbish' (��������]ks��q�) te zien aan content? En niet de data die ik juist wil hebben? Ik lijk wel iets te missen ofzo?
Wel zie ik eventjes in de console dat hij netjes via GZIP zijn mooie xml-feed krijgt?
Maar dan opeens lijkt hij de Gzip te vergeten, en zie ik weer een hoop heximale tekens?

Ik ben er geen superheld in, maar ben al blij dat ik het nodige met een hoop ge-debug en manuals werkend heb. Tot op dit probleem met Gzip....
Iemand?

En mocht iemand ideeën hebben voor simpele verbeteringen aan de code. Kom maar op...

[ Voor 25% gewijzigd door AW_Bos op 29-11-2017 01:26 ]

[Verwijderd]

zo even op eerste blik, moet regel 16

JavaScript:

res.writeHead(200, {'Content-Type': 'text/plain'}); 

moet text/plain niet text/xml zijn?
en als je het resultaat opslaat in een var en dan bekijkt in de console is het dan ook onleesbaar of niet?

[Feanathiel]

Ik zie zo snel even niet gzip toegepast worden op de server? Wat je nu zegt als client is: 'graag gzip als het kan'. En wat de server nu terug stuurt is: 'hier heb je normale text'. De browser kan hiermee omgaan, omdat deze reageert op de 'content-encoding' response-header. Wat er hier met de client gebeurd is dat er gunzip wordt toegepast ongeacht wat je terug krijgt. En gzip-decompression op plain-text, daar krijg je bende op terug.

[AW_Bos]

@Feanathiel Hoe valt dit op te lossen?
Want er gaat gewoon gzip over de data in de socket heen. Verder moet de boel wel weer gedeflated worden.

Verder wordt zlib gewoon aangeroepen.

[ Voor 32% gewijzigd door AW_Bos op 29-11-2017 19:43 ]

[Feanathiel]

Ben verder niet zo bekend met de zeromq.js library, maar probeer het eens met:

JavaScript:

sock.on('message', function(topic, message) {
    var buf = new Buffer(message.toString(), 'utf-8');
    zlib.gzip(buf, function (_, result) {
        res.end(result);
    });

    console.log('received a message related to:', topic, 'containing message:', message);
});

Waarbij je dan even moet kijken of de buffer dan goed aangemaakt wordt. Kan maar zo zijn dat je de message gewoon direct kunt gebruiken (als het een TypedArray is).

Uiteraard is het nog mooier wanneer er gecontroleerd wordt of de accept-header wel 'gzip' is, en de content-encoding header wordt terug gestuurd.

[ Voor 21% gewijzigd door Feanathiel op 29-11-2017 21:32 ]

[AW_Bos]

Hmm, dit blijft nog vreemde tekens opleveren. Maar dan wel direct.
Met de code uit mijn startpost krijg ik eerst wel eventjes (in het eerste frame?) in de console de XML-feed te zien, en dan krijg ik weer binaire en hexadecimale bende te zien.

Die Gzip-controle ga ik zeker wel inbouwen, geen slecht idee als mijn provider eens het roer om zou gooien.

Verwijderd schreef op woensdag 29 november 2017 @ 16:33:
zo even op eerste blik, moet regel 16

JavaScript:

res.writeHead(200, {'Content-Type': 'text/plain'}); 

moet text/plain niet text/xml zijn?
en als je het resultaat opslaat in een var en dan bekijkt in de console is het dan ook onleesbaar of niet?

Aangepast, maar dit is niet de oplossing, wel iets om het script inderdaad correcter te maken. Plus dat Firefox het volgens mij netjes wil formatten. Maar dat zijn bijzaken

Tja, als iemand nog ideeën heeft? Ik twijfel aan die stdout. is dat überhaupt wel de oplossing?

[ Voor 73% gewijzigd door AW_Bos op 29-11-2017 22:24 ]

[AW_Bos]

Heeft iemand misschien nog ideeën?

[Xiphalon]

Dat je eerste data wel goed overkomt en de rest niet is wel maf. Zou het kunnen dat je tussen de berichten de gzip opnieuw moet initializeren en dat je dat vergeet?
Dus: je stuurt nu alle berichten door 1 gzip decoder heen, die na het 1e bericht het niet meer snapt, in plaats van elk bericht door een eigen gzip decoder heen te halen.