How does the nodejs http.IncomingMessage object handle multiple WWW-Authenticate headers in a response given that the HTTP specification supports this and that the response headers seem to be made available only through the response.headers object which is header-name : value?
Multiple WWW-Authenticate headers are string-concatenated into a single www-authenticate property, separated by a comma + space.
For example,
GET / HTTP/1.1
WWW-Authenticate: foo
WWW-Authenticate: bar
Will result in
req.headers['www-authenticate'] == 'foo, bar'
This is in line with RFC 2616 ยง 4.2, which states:
Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.
Related
I have a Node JS application running with Express and mongodb. I have a use case where my device sends data to my server. It might be JSON data or Comma-Separated String(Only String, not CSV file). I need to check which type of data is coming and manipulate that to JSON if request body would be a String. When I was trying to display the data type of data being sent to the server, it's displaying as "object" even after giving the "String" data as input. And the operation is getting successful but data is not inserting into the database. Can anyone help me in resolving this issue?
Sample Payload(request.body) would be,
"heat:22,humidity:36,deviceId:sb-0001"
Expected response is,
{
"heat": "22",
"humidity": "36",
"deviceId": "sb-0001"
}
#Aravind Actually typeof will returns "string" if operand is a string.So please check whether the string is coming or not in body, because if it is null then typeof will return "object".
I need to check which type of data is coming and manipulate that to JSON ...
HTTP is build upon the media-type concept that defines the syntax used in the payload of that type as well as the semantics of the elements used within that payload. You might take a look at how HTML defines forms to get a grip what a media-type specification should include. Through content negotiation client and server agree on a common media-type and thus a representation format to exchange payloads for supported by both. This simply increases interoperability between the participants as they exchange data in well-defined, hopefully standardized, representation formats both understand and support.
Through Accept headers a receiver can state preferences on which types to receive, including a weighting scheme to indicate that a certain representation format is preferred over an other one but the recipient is also fine with the other one, while a Content-Type header will indicate the actual representation format being sent.
RFC 7111 defines text/csv for CSV based representations and RFC 8259 specifies application/json for JSON payload. As the sender hopefully knows what kind of document it sends to the receiver, you can use this information to distinguish the payload on the receiver side. Note however that according to Fielding true REST APIs must use representation formats that support hypertext-driven interaction flows to allow clients to take further actions upon the payload received without having to invoke some external documentation. Both, JSON and CSV, by default don't support such an interaction model, that is abreviated with the term HATEOAS. For your simple scenario the content type negotiation might though be sufficient enough to solve your needs.
In terms of processing CSV and converting the data to JSON this is simply a matter of splitting up the CSV string on the delimiter symbol (, in the sample) to key-value pairs and then splitting the key and values further on the : symbol and adding these to a new JSON object. There is also a csvtojson library available at NPM that you might utilize in such a case.
I would like to do a DELETE request with unspecified number of parameters a=someValue. There is 2 main ways of supplying parameters to my understanding
Query parameters. ?a=someValue . This approach turn everything into
string and since I allow any number of parameters, I cannot know
which one is String, Boolean or Integer
Parameters in Body.This approach goes against the spec of DELETE operation to not have a body. Some server even strip away the body-content. But as I
send an json object, user can specify which type of value each of
their parameters has.
What would be your approach for this?
I'd use query parameters over body as the DELETE method has an optional body. Some clients may choose to ignore the body totally.
In some special cases, there would exist http request headers which have duplicate values, such as XFF headers appended as following in header:
x-forwarded-for: *.*.*.*
x-forwarded-for: *.*.*.*
And by use of npm package express and request, could we parse the duplicate headers in following code?
req.headers['x-forwarded-for']
The duplicate HTTP headers will be combined into an comma-separated list, so your example the
'x-forwarded-for': '1.2.3.4'
'x-forwarded-for': '5.6.7.8'
will become
'x-forwarded-for': '1.2.3.4, 5.6.7.8'
This is done per HTTP RFC2616 available here:
Multiple message-header fields with the same field-name MAY be present
in a message if and only if the entire field-value for that header
field is defined as a comma-separated list [i.e., #(values)]. It MUST
be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the interpretation
of the combined field value, and thus a proxy MUST NOT change the
order of these field values when a message is forwarded
Here you can find a related issue in node.
How to retrieve header values when I combine two different messages using Aggregator. I have two messages with different header but with same UUID. When I combine these two messages using aggregator with uuid, I do not find a way to retrieve header in custom Aggregator class. does it mean header values are lost? Pls help.
The aggregated message gets a UNION of all the headers. However if there is a conflict, the aggregator doesn't know which value to use so the header is dropped, with this debug message...
logger.debug("Excluding header '" + keyToRemove + "' upon aggregation due to conflict(s) "
+ "in MessageGroup with correlation key: " + group.getGroupId());
If you need to retain the values, they need to be in different headers.
Why are there hexadecimal numbers included in my view results from CouchDB? How can I get rid of them?
7f
{"total_rows":108,"offset":0,"rows":[
{"id":"5c718dbd01bc0cde8152e08ed6003405","key":"2013-03-19T22:43:27.2683661Z","value":0}
5b
,
...
{"id":"5c718dbd01bc0cde8152e08ed6037404","key":"2013-03-19T23:07:35.5972058Z","value":0}
5b
,
{"id":"5c718dbd01bc0cde8152e08ed60376e5","key":"2013-03-19T23:07:35.6062063Z","value":0}
4
]}
1
0
TL;DR
I am new to CouchDB, and are investigating its use as a database for an event log. I have created a simple map function to view the event log by date:
function(doc)
{
if (doc.DateTime)
{
emit(doc.DateTime, doc);
}
}
When I use Fiddler to test this view with the following request:
GET http://localhost:5984/stuff/_design/eventlog/_view/datetime
Host: localhost:5984
User-Agent: Fiddler
The results returned included hexadecimal numbers that aren't a part of the JSON structure. Hence the JSON returned is invalid. Why are these hexadecimal numbers included in the results, and how can I get rid of them?
I am using Windows (x86) CouchDB version 1.2.1.
The weird hex numbers are used for so-called chuncked transfer-encoding. This is a way for HTTP responses to become available in a streaming format instead of the client having to wait for entire response to be ready. The hex numbers denote the length for the next chunk.
I think the use of chunking is independent of the request's Accept values, but I'm not sure.
To get a pure JSON result you must include the Accept: application/json header in your HTTP request.
If you omit the the Accept header CouchDB will return results in a manner that is more suitable for displaying nicely in web browsers. The results will be in a JSON format, but with a text/plain content-type.
See Apache CouchDB 1.3 Manual Section 2.2.1. Request Headers.
The hexadecimal numbers are a result of Chunked transfer encoding.