I have read through the documentation (both API and Manual), and haven't seem to find any support by gwan for the X-Forwarded-For header. The only thing I have found that could be related was REMOTE_BIN_ADDR.
I know to get a client IP you can use REMOTE_ADDR however my gwan servers are behind a HA Proxy load balancer, which forwards the client IP via X-Forwarded-For.
Does Gwan not support this header?
As far as we know, while widely used, the X-Forwarded-For HTTP header is not part of the RFCs. Some servers, like Nginx, are using alternatives because proxy servers can "chain" the client IP address, leading to unreliable results.
On a side note, keep in mind that HTTP headers providing an X-Forwarded-For value cannot be trusted... unless your own proxy is cleaning-up any previously setup value and adding its own. This makes this X-Forwarded-For header less useful than expected at first glance - and surely contributes to explain why Nginx felt the need to create its own.
G-WAN initially supported this header but we have removed this entry because we believe that it is redundant with the native G-WAN reverse-proxy and load-balancer (a feature that was implemented last year but which is still not documented as documenting and exporting the interfaces in a polished way takes time - and we want to merge this feature with protocol handlers, to simplify things).
Note that, right now, you can easily parse it from the HTTP headers exposed by G-WAN, either from a handler or from servlets.
Related
I'm just starting to develop a SPA, with java(dropwizard) REST backend. I'm kinda new to 'web' development, but I did internal web apps before, so security was not a big concern before.
Right now I'm using nginx as my public facing web server, and I just discovered whole slew of complications that arise as we're splitting actual servers: static web server serving my SPA's files, and java microservices behind it.
I'm used to apache talking to tomcat with mod_jk, but now I had to implement CORS in dev because my SPA is deployed on a lite-server serving at different port than the REST Api served by dropwizard.
Now I got to my minimum viable product and wanted to deploy it on prod,
but I have no idea how do I do it.
Do I still need the CORS header? Dropwizard will be run separately on a different port only available to local processes, then I configure nginx to route incoming request from, e.g. /api/ to that port. Does that counts as cross-origin?
I'd like to serve full https. Dropwizard can serve to https, but I don't want to update SSL cert on multiple microservices. I read about nginx ssl termination, will this enable me to use plain http in local and https on nginx?
Any other caveats to watch out on deploying with this architecture?
Thank you!
Yes, you can certainly do it!
You can terminate https with nginx, and still have the backend operate on either plain http or even https still. The proxy_pass directive does support both access schemes for the upstream content. You can also use the newer TCP stream proxying, if necessary.
There are not that many caveats, really. It usually just works.
I'm designing a REST web API, but noticed something weird lately.
Apparently some proxy servers are blocking specific HTTP request methods. In my case the PUT and PATCH methods which are crucial to modify resources. This partially breaks the functionality of the API I'm designing...
Is there a good way to bypass this problem without breaking the RESTful architecture constraints? In my opinion there isn't, because fully using the HTTP verbs is advocated when designing a REST web API over HTTP...
You have a few options:
Ignore it. People who willingly break the(ir) web (experience) using a malconfigured proxy server will have to deal with the consequences themselves.
Ask the proxy administrators to whitelist your host or the methods it accepts.
Rewrite your API, "breaking" REST principles.
Use HTTPS, so the proxy will only see the connect method.
I'm writing a RESTful API service, that will only work through HTTPS protocol. What kind of response code should be returned if the request comes via HTTP?
"301 Moved Permanently" where the server redirect the client from a http to https. This is the most commonly used pattern and what I would recommend you to implement on a server level. Implementation of this depend on the webserver your have and I would guess that there is plenty of good guide online to your specific server.
This will also tell the client to switch from HTTP to HTTPS Permanently.
If the question was more related to method rather than HTTP/HTTPS then "405 METHOD NOT ALLOWED" would be the correct choice. This is what you should respond to a client if the client is not not allowed to call the method itself. This would be misleading as a first step since the HTTP/HTTPS protocol is the problem and not the method (Get, Post, Put etc.) utilized by the client.
426 Upgrade Required. This suggest that https should be used.
I'm looking at various methods of RESTfully versioning APIs, and there are three major contenders. I believe I've all but settled on using X-API-Version. Putting that debate aside, one of the arguments against using that header, and custom headers in general, is that you can't control when headers are manipulated by proxy servers. I'm curious about what real-world examples there are of this, when it happens on the internet at large, or when it might be used on an intranet or server cluster, or when it might occur in any other situation.
The Guidelines for Web Content Transformation Proxies 1.0 is pretty much the definitive guide to understanding and predicting standards-compliant proxy server behavior. In terms of your question, the Proxy Forwarding of Request portion of the document might be especially helpful.
Each proxy software package and their individual configurations will be vary but, HTTP proxies are generally expected to follow the W3C Guidelines. Here are some highlights.
4.1 Proxy Forwarding of Request:
Other than to convert between HEAD and GET proxies must not alter request methods.
If the request contains a Cache-Control: no-transform directive, proxies must not alter the request other than to comply with transparent HTTP behavior defined in [RFC 2616 HTTP] sections section 14.9.5 and section 13.5.2 and to add header fields as described in 4.1.6 Additional HTTP Header Fields below.
4.1.3 Treatment of Requesters that are not Web browsers
Before altering aspects of HTTP requests and responses proxies need to take account of the fact that HTTP is used as a transport mechanism for many applications other than "Traditional Browsing". Increasingly browser based applications involve exchanges of data using XMLHttpRequest (see 4.2.8 Proxy Decision to Transform) and alteration of such exchanges is likely to cause misoperation.
4.1.5 Alteration of HTTP Header Field Values
Other than the modifications required by [RFC 2616 HTTP] proxies should not modify the values of header fields other than the User-Agent, Accept, Accept-Charset, Accept-Encoding, and Accept-Language header fields and must not delete header fields (see 4.1.5.5 Original Header Fields).
Other than to comply with transparent HTTP operation, proxies should not modify any request header fields unless one of the following applies:
the user would be prohibited from accessing content as a result of the server responding that the request is "unacceptable" (see 4.2.4 Server Rejection of HTTP Request);
the user has specifically requested a restructured desktop experience (see 4.1.5.3 User Selection of Restructured Experience);
the request is part of a sequence of requests comprising either included resources or linked resources on the same Web site (see 4.1.5.4 Sequence of Requests).
These circumstances are detailed in the following sections.
Note:
It is emphasized that requests must not be altered in the presence of Cache-Control: no-transform as described under 4.1.2 no-transform directive in Request.
The URI referred to in the request plays no part in determining whether or not to alter HTTP request header field values. In particular the patterns mentioned in 4.2.8 Proxy Decision to Transform are not material.
4.1.6 Additional HTTP Header Fields
Irrespective of the presence of a no-transform directive:
proxies should add the IP address of the initiator of the request to the end of a comma separated list in an X-Forwarded-For HTTP header field;
proxies must (in accordance with RFC 2616) include a Via HTTP header field (see 4.1.6.1 Proxy Treatment of Via Header Field).
There is also lots of information regarding the alteration of response headers and being able to detect those changes.
As for web service REST API versioning, there is a very lucid and useful SO thread at Best practices for API versioning? that should provide a wealth of helpful insight.
I hope all of this helps. Take care.
This isn't an answer per se, but rather a mention of real-world scenario.
My current environment uses a mixed CAS/AD solution in order to allow SSO across several different platforms (classic ASP, ASP.NET, J2EE, you name it).
Recently we identified some issues - part of the solution involves aggregating Auth tokens to HTTP headers whenever necessary to propagate credentials. One specific solution, making considerable heavy usage of cookies, was chained with an nginx implementation, whose HTTP header limit was set to 4KiB. If the cookie payload went over 2KiB, it would start leaking out headers.
Consequently, applications that had some sort of state/scope control being coordinated via HTTP headers (session cookies included) suddenly started behaving erratically.
On an interesting, related note, REST services using URL versioning (http://server/api/vX.X/resource, for example) were unaffected.
I have a service that always returns the same results for a given parameter. So naturally I would like to cache those results on the client.
Is there a way to introduce caching and other effect inside the WCF pipeline? Perhaps a custom binding class that could site between the client and the actual HTTP binding.
EDIT:
Just to be clear, I'm not talking about HTTP caching. The endpoint may not necessarily be HTTP and I am looking at far more effects than just caching. For example, one effect I need is to prevent multiple calls with the same parameters.
The WCF service can use Cache-Control directives in the HTTP header to say the client how it should use the client side cache. There are many options, which are the part of HTTP protocol. So you can for example define how long the client can just get the data from the local cache instead of making requests to the server. All clients implemented HTTP, like all web browsers, will follow the instructions. If your client use ajax requests to the WCF server, then the corresponding ajax call just return the data from the local cache.
Moreover one can implement many interesting caching scenarios. For example if one set "Cache-Control" to "max-age=0" (see here an example), then the client will always make revalidation of the cache by the server. Typically the server send so named "ETag" in the header together with the data. The "ETag" represent the MD5 hash or any other free information which will be changed if the data are changed. The client send automatically the "ETag", received previously from the server, together inside the header of the GET request to the server. The server can answer with the special response HTTP/1.1 304 Not Modified (instead of the typical HTTP/1.1 200 OK response) and with the body having no data. In the case the client will safe to get the data from the local cache.
I use "Cache-Control:max-age=0" additionally with Cache-Control: private which switch off caching the data on the proxy and declare that the data could be cached, but not shared with another users.
If you want read more about caching control with respect of HTTP headers I'll recommend you to read the following Caching Tutorial.
UPDATED: If you want implement some general purpouse caching you can use Microsoft Enterprise Library which contains Caching Application Block. The Microsoft Enterprise Library are published on the CodePlex with the source code. As an alternative in .NET 4.0 you can use System.Runtime.Caching. It can be used not only in ASP.NET (see here)
I continue recommend you to use HTTP binding with HTTP caching if it only possible in your environment. In the way you could save many time of development and receive at the end more simple, scalable and effective application. Because HTTP is so important, one implemened already so much useful things which you can use out-of-the-box. Caching is oly one from the features.