Akka HTTP - How to get the raw (not URL decoded) request URL? - http

I am using Akka HTTP and having the following HTTP request:
http://www.example.com?p1=1&p2=2&p3=http://www.example.net?a=1&b=2%203
Is there a way in Akka HTTP to get the full raw (not URL decoded) request URL? I would like to get the full raw request URL as it is
http://www.example.com?p1=1&p2=2&p3=http://www.example.net?a=1&b=2%203
parse it and get everything after "p3=".

Turn on the akka.http.server.raw-request-uri-header configuration setting, and the raw request URI will be included as the value for a header named Raw-Request-URI.
In other words, in your application.conf, set the following:
akka.http.server.raw-request-uri-header = on
Then obtain the raw request URI from the Raw-Request-URI header.
From the documentation:
Sometimes it may be needed to obtain the “raw” value of an incoming URI, without applying any escaping or parsing to it. While this use case is rare, it comes up every once in a while. It is possible to obtain the “raw” request URI in Akka HTTP Server side by turning on the akka.http.server.raw-request-uri-header flag. When enabled, a Raw-Request-URI header will be added to each request. This header will hold the original raw request’s URI that was used. For an example check the reference configuration.

Related

Is there a way to set the http Header values for an esp_https_ota call?

I'm trying to download a firmware.bin file that is produced in a private Github repository. I have the code that is finding the right asset url to download the file and per Github instructions the accept header needs to be set to accept: application/octet-stream in order to get the binary file. I'm only getting JSON in response. If I run the same request through postman I'm getting a binary file as the body. I've tried downloading it using HTTPClient and I get the same JSON request. It seems the headers aren't being set as requested to tell Github to send the binary content as I'm just getting JSON. As for the ArduinoOTA abstraction, I can't see how to even try to set headers and in digging into the esp_https_ota functions and http_client functions there doesn't appear to be a way to set headers for any of these higher level abstractions because the http_config object has no place for headers as far as I can tell. I might file a feature request to allow for this, but am new to this programming area and want to check to see if I'm missing something first.
Code returns JSON, not binary. URL is github rest api url to the asset (works in postman)
HTTPClient http2;
http2.setAuthorization(githubname,githubpass);
http2.addHeader("Authorization","token MYTOKEN");
http2.addHeader("accept","application/octet-stream");
http2.begin( firmwareURL, GHAPI_CERT); //Specify the URL and certificate
With the ESP IDF HTTP client you can add headers to an initialized HTTP client using function esp_http_client_set_header().
esp_http_client_handle_t client = esp_http_client_init(&config);
esp_http_client_set_header(client, "HeaderKey", "HeaderValue");
err = esp_http_client_perform(client);
If using the HTTPS OTA API, you can register for a callback which gives you a handle to the underlying HTTP client. You can then do the exact same as in above example.

What is the difference between client HTTP request and server HTTP request in Golang's "net/http"

I have seen people use NewRequest() method of the "net/http" package for testing APIs. Why not use the NewRequest() method from "net/http/httptesting"? What's the difference? Documentation advises the following:
// To generate a client HTTP request instead of a server request, see
// the NewRequest function in the net/http package.
What would be the difference in handling cookies, for example? Both seem to be very similar.
TL;DR: they're the same type, used a bit differently for two use cases and initialized differently to serve these use cases
The difference is only in usage - they are the same type http.Request. http.NewRequest is used for the more "production" use case which is client - "create a new request to send to the server". When writing HTTP servers, it's occasionally useful to create requests for testing, which is what httptest.NewRequest does. The doc of http.NewRequest is helpful here:
NewRequest returns a Request suitable for use with Client.Do or
Transport.RoundTrip. To create a request for use with testing a Server
Handler, either use the NewRequest function in the net/http/httptest
package, use ReadRequest, or manually update the Request fields. See
the Request type's documentation for the difference between inbound
and outbound request fields.
If you check the docs of the http.Request type, you'll find things like:
// URL specifies either the URI being requested (for server
// requests) or the URL to access (for client requests).
//
// For server requests, the URL is parsed from the URI
// supplied on the Request-Line as stored in RequestURI. For
// most requests, fields other than Path and RawQuery will be
// empty. (See RFC 7230, Section 5.3)
//
// For client requests, the URL's Host specifies the server to
// connect to, while the Request's Host field optionally
// specifies the Host header value to send in the HTTP
// request.
URL *url.URL
Note the "For client requests" vs. "For server requests".
If you see a place that doesn't use httptest.NewRequest it could be because:
They're not aware of it
Or they need more careful fine-tuning that http.NewRequest doesn't provide

HTTP status code for sending back just the meta-data not full data

I am looking for an appropriate HTTP status code that tells the receiver that just the meta-data is being sent, not the complete data.
For example, say you do an HTTP GET:
GET /foo?meta_data_only=yes
the server won't look up the complete data, just send some metadata back about the endpoint, for example. Is there an HTTP status code for the response that can represent this? I would guess it's in the 200s or 300s somewhere?
Since your metadata is being returned in the headers, I would send a status code of 204 No Content.
https://httpstatuses.com/204
The server has successfully fulfilled the request and that there is no
additional content to send in the response payload body.
Metadata in
the response header fields refer to the target resource and its
selected representation after the requested action was applied.
This sounds exactly like what you’re looking for: a successful response that contains no body, and metadata in the headers that provide additional about the resource.
Another thing worth noting is that it’s common practice to use the HTTP verb HEAD when you only want metadata. HEAD is very similar to GET, except that it specifies that you do not want a body back. For example if you do a HEAD to an image url, you will get a 204 No Content response and some metadata about the file such as Content-Type, Content-Size, maybe ETag, but you won’t be sent all of the file data. A lot of web servers (such as Nginx) support this behavior out of the box for static files. I would recommend that you stop using your querystring parameter, and instead implement HEAD versions of your endpoints. That would make the intention even more clear and intuitive.

Is it possible to generate complete url from http response header

I wish to get the complete url of file being set by server through its http-header(response). I am doing some sort of packet filtering. Is it possible to generate complete url from http response header.
No, it's not possible. You need the actual HTTP request.

Does REST send its payload in the URL of the request? What about SOAP?

Do SOAP and REST put their respective payloads as a URL? For example:
http://localhost/action/?var=datadatadata
I know SOAP uses XML and sometimes runs on a different port on the server, but do you still submit data like the example above or do you send it as one big XML encapsulated packet to that port?
It depends on your HTTP method. GET method will put everything into URL while POST method only put path information in URL and the rest of them are streamed into the HTTP request body.
SOAP should also rely on HTTP protocol and hence should follow the same rule. Check out http://www.w3.org/TR/soap12-part0/#L10309

Resources