When considering a three-tier architecture with
FrontEnd Client
AppServer
Database server
and when the URL is encoded in the Browser(Frontend client) where does URL decoding happen? Is it AppServer or Database?
Br,
Hemanshu.
In this scenario, the web application server will typically handle URL decoding. (I feel like I should provide more detail/explanation, but I don't know what the motivation is for asking, so I'm not sure what more to include.)
Related
I was playing around with GZIP compression recently and the way I understand the following:
Client requests some files or data from a Web Server. Client also sends a header that says "Accept-Encoding,gzip"
Web Server retrieves the files or data, compresses them, and sends them back GZIP compressed to the client. The Web Server also sends a header saying "Content-Encoded,gzip" to note to the Client that the data is compressed.
The Client then de-compresses the data/files and loads them for the user.
I understand that this is common practice, and it makes a ton of sense when you need to load a page that requires a ton of HTML, CSS, and JavaScript, which can be relatively large, and add to your browser's loading time.
However, I was trying to look further into this and why is it not common to GZIP compress a request body when doing a POST call? Is it because usually request bodies are small so the time it takes to decompress the file on the web server is longer than it takes to simply send the request? Is there some sort of document or reference I can have about this?
Thanks!
It's uncommon because in a client - server relationship, the server sends all the data to the client, and as you mentioned, the data coming from the client tends to be small and so compression rarely brings any performance gains.
In a REST API, I would say that big request payloads were common, but apparently Spring Framework, known for their REST tools, disagree - they explicitly say in their docs here that you can set the servlet container to do response compression, with no mention of request compression. As Spring Framework's mode of operation is to provide functionality that they think lots of people will use, they obviously didn't feel it worthwhile to provide a ServletFilter implementation that we users could employ to read compressed request bodies.
It would be interesting to trawl the user mailing lists of tomcat, struts, jackson, gson etc for similar discussions.
If you want to write your own decompression filter, try reading this: How to decode Gzip compressed request body in Spring MVC
Alternatively, put your servlet container behind a web server that offers more functionality. People obviously do need request compression enough that web servers such as Apache offer it - this SO answer summarises it well already: HTTP request compression - you'll find the reference to the HTTP spec there too.
Very old question but I decided to resurrect it because it was my first google result and I feel the currently only answer is incomplete.
HTTP request compression is uncommon because the client can't be sure the server supports it.
When the server sends a response, it can use the Accept-Encoding header from the client's request to see if the client would understand a gzipped response.
When the client sends a request, it can be the first HTTP communication so there is nothing to tell the client that the server would understand a gzipped request. The client can still do so, but it's a gamble.
Although very few modern http servers would not know gzip, the configuration to apply it to request bodies is still very uncommon. At least on nginx, it looks like custom Lua scripting is required to get it working.
Don't do it, for no other reason than security. Firewalls have a hard or impossible time dealing with compressed input data.
I am a beginner to ios development.
Can anyone tell me how to send data to server in xcode?
I have a requirement where I need to send device information to a server.
You need to first work out what kind of API the server you're talking to has exposed
Most modern web applications expose a Rest API (although I can only speculate as to what the server you mention is exposing). If Rest, then a good starting point should you not wish to write your own network layer is to use Restkit: https://github.com/RestKit/RestKit
If not Rest, then you need information on what the backend API is, and then go from there...
In it's most basic format you'll need to look at using NSURLRequest and NSURLConnection
NSURLRequest : Post data and read the posted page
http://codewithchris.com/tutorial-how-to-use-ios-nsurlconnection-by-example/
I'm developing a project with Delphi 2010, at some point this project connects to internet and send some data to a php file via POST/IDHTTP, those parameters encrypted with aes and as you know there is no way to get source code of php files via browser. But when i use sniffer on my project sniffer software shows full path of php file and parameters. I was wondering is there any chance to hide path and parameters with IDHTTP. For example when i try on Skype sniffer only shows decimal characters on skype's transmission. Is it possible to do same or totally hide the traffic ?
Thanks in advance.
You can use HTTPS, it is supposed to be standard way to transmit HTTP traffic through SSL-protected channel. Example of code you can find for example here.
In addition to Andrei's answer, you can consider encrypting your traffic on-top of using HTTPS.
In other words,
1) Use HTTPS protocol.
2) Add your own layer of encryption to encrypt all data coming to and from your server.
In addition to HTTPs and encrypted data, you can also add security by using client certificates. See https://security.stackexchange.com/questions/3605/certificate-based-authentication-vs-username-and-password-authentication
The answers explain the advantages of using CBA, one of them is
certificate usage never involves revealing any secret data to the
peer, so an attacker impersonating the server cannot learn anything of
value that way
I have wrote a simple Django web service that provides an iOS app with JSON information containing download links.
I don't mind the JSON information to be clear text, but when the user logs in, I would like him to login with his username and password, then he would probably get some kind of key for future requests which I understand that can be sniffed out. For that first interaction, how could I protect the password and username from being clear text and sniffed?
I have decided I wanted to use a symmetric encryption to encrypt my password and have that key both on client and on server. (yes, I am aware that if someone goes to the trouble of binary hacking my app and sniffing packets from a customer he would be able to get the password in clear text, it's just not a likely concern).
I would like to use some kind of encryption that I can easily do in iOS and than decrypt in my django server. anyone has a suggestion on how to do that?
If you want to encrypt the communication between your django server and the client then you can use secure HTTP rather than plain old HTTP. This is done outside django, and is configured at the web server level. For example, if your django app is ran by a WSGI server like gunicorn or uWSGI which in return is handled by nginx (this is a common setup) then you would configure your nginx server to accept only secure HTTP requests and forward any standard http request to https. This way you can ensure that everything the client sends to the server is encrypted on the browser prior to sending. Similar setup is done with Apache, though I personally have never used Apache with django.
Since the OP feels that HTTPS is not a viable option a modification of CHAP Challenge-Handshake Authentication Protocol for the initial key creation might be an option.
How can I future-proof my client URL links to my server for future HTTPS migration?
I have a .net winforms client talking to my ruby on rails backend. If I move the website in the future I want to make sure that my API links from the client don't have to change.
Or is this something a hosting provider can let you configure.
Oh, and when I do migrate I will not want any non HTTPS to occur.
PS1 - I am not talking about moving servers here, just upgrading the existing web application server with a certificate and moving to HTTPS only traffic
Place a base url as a config parameter in your client application, then run all new links through a getLinkURL(String relativeDestination) method which will give you a full url.
If you're worried about clients that haven't been updated making non-http requests, in your http (non-secure) vhost just Redirect 301 / https:// on your server.
If I understand the question correctly, I think you can solve this by using relative links everywhere; unless there's a reason you can't do that?
I think you need to look into DNS and how it works. It's not going to protect you against an HTTP to HTTPS migration but would allow you to move servers without re-engineering your code. Ideally I think you'd look to have a config setting in your code to switch from HTTP to HTTPS (and back) when necessary.