Is it possible for requests to the API-Gateway to pass the referrer URL to Lambda? For example, I'd love to let my lambda functions know if a request comes from the domain "good.com" vs. "bad.com".
I'm familiar with the list of supported $context Variables and I know a referrer url is not in there. I'm wondering if there is another way. If it is possible, what steps do I need to take?
Here's how to do it.
As it turns out, the mapping template allows you to map HTTP headers, not just the list of supported variables in the documentation.
The HTTP header that contains the referrer domain is called "Origin". The header that contains the referer page URL is called "Referer".
So, for example, you can put this in your mapping template and it will grab the associated header information:
{
"origin" : "$input.params('origin')",
"referer" : "$input.params('referer')"
}
Origin grabs example.com. Referer grabs example.com/pagename
It's an HTTP header, so if you are mapping HTTP headers in the template it will be passed to the Lambda function. Look at this answer for an example of how to map HTTP headers in the request template.
Related
I need to route a message from API Gateway to a specific queue regarding URL Path.
By example:
/queues/{queueId} -> API GW routes /queues/queue1 URL to SQS queue1
Is it possible to do it "simply" only with API GW config or do I need to use a lambda to make the routing to the right queue ? or any other solution ?
It is possible to do that.
While configuring integration on Path Override you need define it like 12345678/{queueId} (12345678 is your account id).
Then you need to define URL PATH Parameters
Name queueId, Mapped from method.request.path.queueId
Expand HTTP headers add new Header with Name Content-Type, Mapped from as 'application/x-www-form-urlencoded'
Add a Mapping Templates as Content-Type application/json and template body as Action=SendMessage&MessageBody=$input.body
When a client browser receives a 302 response, does the browser modify or ignore any parameters appended to the end of the URL?
For example, I have a server that redirects requests to a different URL but retains any parameters from the original URL and appends to the end of the new redirect URL. However, browser is not including the parameters in the new URL.
For example, if a request comes in to "https://server1.com/path1?filter=value", the redirect server responds with a 302 and "location: https://server2.com/path2?filter=value". But, issue is that the client browser seems to only recognize "https://server2.com/path2".
Should parameter values be tagged a different way in the response?
As noted by Remy Lebeau in the comments to the question, the browser does not modify the location URL in the 302 response. Rather, the issue was caused by the networking in AWS - I was using AWS Lambda to perform the re-direct by reading in the URL on the original request coming in and re-directing according to mapping in the function. First issue was that API gateway was stripping off the query parameters before it was hitting the Lambda function. Second issue was that the function read the "rawPath" attribute from the request, but this does not contain URL query parameters; the query parameters are contained in the "rawQueryString" attribute instead.
I'm using fiddler to test a Web API service I'm writing.
I know I can pass parameters to a RESTful web service in the querystring with a request like -
www.example.com/api/Book?Id=123&category=fiction.
Are there other ways of passing the parameters to the service, while still using a GET.
There are many parts of the HTTP request which you can use to pass parameters, namely the URI, headers and body. GET requests don't have bodies (some frameworks actually allow that, but they're not common so for all purposes, let's just assume that they can't), so you're limited to the headers and the URI.
In the URI you can pass parameters in different places:
Query string (as you're already doing)
Ex.: www.example.com/api/Book?Id=123&category=fiction
Request path
Many frameworks will allow you to get parameters to your actions from paths in the request URI. With ASP.NET Web API you'd typically do that using routing
Ex.: www.example.com/api/Book/fiction/123
In the fragment, or the part of the URI after the # character. See the URI RFC, section 3.5.
Ex.: www.example.com/api/Book?Id=123&category=fiction#somethingElse
You can also pass paramters in the HTTP request headers. One parameter which is honored by the ASP.NET Web API is the Accept header, which is used when doing content negotiation. You can also expect custom parameters from those headers, and read them in your actions (or even have value providers which will read them and map them to the parameters in the methods themselves).
I'm working on a REST API using the FOSRestBundle and I'd like to be able to use the same URL for returning HTML and JSON depending on the request Accept header; i.e. if you call the URL directly from a browser (Accept : text/html etc) HTML is returned from a twig file, if you are making an AJAX request (Accept : application/JSON etc), JSON is returned using the FOSRestBundle.
Currently I can get this to work by throwing a small if statement at the top of each function to check the request accept header, if it's asking for HTML it returns the twig file, if it's asking for JSON it hits the service.
You should rather send "Accept" header with your requests. Read content negotiation (“Accept” HTTP header) based routing in symfony2.0 and Format listener.
The request scope does not exist when run in command line mode, I had to remove request from each constructor and the problem disappeared.
I'm looking into a restful design and would like to use the HTTP methods (POST, GET, ...) and HTTP headers as much as possible. I already found out that the HTTP methods PUT and DELETE are not supported from the browser.
Now I'm looking to get different representations of the same resource and would like to do this by changing the Accept header of the request. Depending on this Accept header, the server can serve a different view on the same resource.
Problem is that I didn't find a way to tell my browser to change this header.
The <a..> tag has a type attribute, that can have a mime type, looked like a good candidate but the header was still the browser default (in Firefox it can be changed in about:config with the network.http.accept.default key).
I would partially disagree with Milan's suggestion of embedding the requested representation in the URI.
If anyhow possible, URIs should only be used for addressing resources and not for tunneling HTTP methods/verbs. Eventually, specific business action (edit, lock, etc.) could be embedded in the URI if create (POST) or update (PUT) alone do not serve the purpose:
POST http://shonzilla.com/orders/08/165;edit
In the case of requesting a particular representation in URI you would need to disrupt your URI design eventually making it uglier, mixing two distinct REST concepts in the same place (i.e. URI) and making it harder to generically process requests on the server-side. What Milan is suggesting and many are doing the same, incl. Flickr, is exactly this.
Instead, a more RESTful approach would be using a separate place to encode preferred representation by using Accept HTTP header which is used for content negotiation where client tells to the server which content types it can handle/process and server tries to fulfill client's request. This approach is a part of HTTP 1.1 standard, software compliant and supported by web browsers as well.
Compare this:
GET /orders/08/165.xml HTTP/1.1
or
GET /orders/08/165&format=xml HTTP/1.1
to this:
GET /orders/08/165 HTTP/1.1
Accept: application/xml
From a web browser you can request any content type by using setRequestHeader method of XMLHttpRequest object. For example:
function getOrder(year, yearlyOrderId, contentType) {
var client = new XMLHttpRequest();
client.open("GET", "/order/" + year + "/" + yearlyOrderId);
client.setRequestHeader("Accept", contentType);
client.send(orderDetails);
}
To sum it up: the address, i.e. the URI of a resource should be independent of its representation and XMLHttpRequest.setRequestHeader method allows you to request any representation using the Accept HTTP header.
Cheers!
Shonzilla
I was looking to do exactly the same thing (RESTful web service), and I stumbled upon this firefox addon, which lets you modify the accept headers (actually, any request headers) for requests. It works perfectly.
https://addons.mozilla.org/en-US/firefox/addon/967/
I don't think it's possible to do it in the way you are trying to do it.
Indication of the accepted data format is usually done through adding the extension to the resource name. So, if you have resource like
/resources/resource
and GET /resources/resource returns its HTML representation, to indicate that you want its XML representation instead, you can use following pattern:
/resources/resource.xml
You have to do the accepted content type determination magic on the server side, then.
Or use Javascript as James suggests.
ModHeader extension for Google Chrome, is also a good option. You can just set the Headers you want and just enter the URL in the browser, it will automatically take the headers from the extension when you hit the url. Only thing is, it will send headers for each and every URL you will hit so you have to disable or delete it after use.
Use some javascript!
xmlhttp=new XMLHttpRequest();
xmlhttp.open('PUT',http://www.mydomain.org/documents/standards/browsers/supportlist)
xmlhttp.send("page content goes here");