I'm a project manager not a developer, and we stood up a really basic site in windows azure, We've now been asked to track usage of the site, and I'm curious what a request is. The site is accessed through a mobile device and performs a basic calculation. So I believe that there is only one request per visit, changing numbers you enter in various fields to what if the calculation doesn't seem to refresh the page. Is that a fair assumption or are there some basic checks I can do to understand if I need to aggregate requests to really track or interpret usage of the site.
Whenever your web browser fetches a file (a page, a picture, etc) from
a web server, it does so using HTTP - that's "Hypertext Transfer
Protocol". HTTP is a request/response protocol, which means your
computer sends a request for some file (e.g. "Get me the file
'home.html'"), and the web server sends back a response ("Here's the
file", followed by the file itself).
That request which your computer sends to the web server contains all
sorts of (potentially) interesting information. We'll now examine the
HTTP request your computer just sent to this web server, see what it
contains, and find out what it tells me about you.
http://djce.org.uk/dumprequest
tip: add google analytics to your site. It will give to you the number of views and unique users.
Related
So I have made a back-end in NodeJS but I ran into one problem, how is it possible to link my back-end to my front end html/css page and use my NodeJS functions as scripts?
In case this wasn't clear to you, your nodejs back-end runs on your server. The server's job (in a webapp) is to deliver data to the browser. It delivers HTML pages. It delivers resources referenced in those HTML pages such as scripts, images, fonts, style sheets, etc.. It can answer programmatic requests for data also.
The scripts in those web pages run inside the browser which is nearly always (except for some developer testing scenarios) running on a completely different computer on a completely different local network (only connected via some network - usually the internet).
As such, a script in the browser cannot directly reference variables that exist in the server or call functions that exist on the server. They are completely different computers.
The kinds of things you can do in order to work-around this architectural limitation are as follows:
The server can dynamically modify the web page it is sending the browser and it can insert data into that web page. That data can be in the form of already rendered HTML or it can be variables inside of script tags that your web page Javascript can then use.
The javascript in the web page can make network requests to your server asking it for data. These are often called AJAX calls. In this scenario, some Javascript in your page sends a request to the server to retrieve some data or cause some action on the server. The server receives that request, carries out the desired operation and then returns a result back to the client Javascript running in the browser. That client Javascript receives the result and can then act on it, inserting data into the page, making the browser go to a new web page, prompting the user, etc...
There are some other ways that the web page javascript can communicate with the server such as webSocket connections, but we'll put those aside for now as they are just more ways for remote communication to happen - the structure of the communication doesn't really change.
how is it possible to link my back-end to my front end html/css page and use my NodeJS functions as scripts?
You can't directly use your nodejs functions as scripts in the front-end. You can make Ajax calls to the server and ask the server to execute it's own server code on your behalf to carry out some operation or retrieve some data.
If appropriate, you can also insert scripts into the web page and run Javascript directly in the browser, but whether you can do that for your particular situation depends entirely upon what the scripts are doing. If the scripts are accessing some resource that is only available from the server (like a database or a server storage system), then you won't be able to run those types of scripts in the browser. You will have to use ajax calls to ask the server to run them for you and then retrieve the results.
Have small app (My first Node js App), where I want add changing real-time content.
For example I have a common url which have list of content link, when user click on particular link it will open its correspondence link.
I have teacher and student role in the app so if teacher open the specific content(From the common url page) then it will automatically open that content for all student who have common url.
Please give me any Idea to implement this functionality and please tell me any plugin who have same functionality for real time content change.
One way, probably the easiest would be to use websockets, an easily manageable choice is socket.io npm package. What makes websockets different from http requests is the direction of the data flow. While http is pull based, meaning that a request has to be made to the server in order to get a response, websockets - once the connection is established - are or at least can be push based, meaning that the server could push out content without having to get a request from the client. In your situation, the teacher and the studens would all have an active websocket connection with the server. When the teacher clicked on a certain view, it would push the view’s data requirements to the students without any interaction from their side and the view would update on their screens according to the pushed data.
Look into how websockets work and try to experiment with a basic socket.io setup.
I tried analyzing what in essence is a website . I thought of deconstructing or reverse engineering a website . The following are the sequence of events, I speculate or theorize the following sequence of events to be taking place during interaction with a website .
1.Every website is basically a set of computer programs,which get executed when the system where they are stored are contacted .
2.Depending on the processing of the type of request sent by the sender , some xml files , files containing the code to be executed,in response to different events and some script purported for dynamic alteration of the xml files are sent. Out of these xml files .
Out of these xml files , one contains the information about the initial appearance of the page and the furnishing of different controls or event generators on the screen .
4.So when some activity is done in the locality of one event generator , like a mouse click , an event is generated .
The code snippet to respond to the event is executed . If the code contains contacting the server and sending some request then the server is again pinged .
When the server is pinged again , depending on the request sent it again executes some code and in response transfers some more code files ,xml files and scripts to dynamically change the appearance of the page .
Is my understanding about the flow of a website correct ?
A web server is basically just a program sitting on a computer that listens on some TCP port (usually 80 for HTTP, 443 for HTTPS).
Clients (such as browsers) can connect and send a request (in HTTP format) to the server.
The server then sends an HTTP response back.
That's it. That's the basic flow: Connect, request, response.
The response contains a "type" field that tells the client what to do with the data. E.g. it could send an image (which is usually displayed on screen), an audio file (which is played), or a "normal" web page in HTML format.
HTML contains structured information about page content and layout, and may contain references to other resources such as images, style sheets, and scripts. A browser automatically fetches these resources (another HTTP request/response) and processes them.
Scripts can be used to customize the behavior on the client side. These are typically written in JavaScript and make use of an API exposed by the browser for interacting with the current page. They can e.g. register "click" handlers to define what happens when the user clicks on some page element.
XML may or may not be used internally by the web server. It doesn't really matter as far as clients are concerned.
If you want to learn more about this, I suggest researching HTTP, HTML, CSS, and JavaScript. MDN has some good articles, for example.
I get this question a lot =/
But I only know how to answer it at a very high level.
From the minute a user enters a URL and hits enter, what happens on the client and server side, and how do requests/responses work? How does the server interact with CGI/interpreters?
It would be helpful too if you could direct me to a URL that has this information in detail, or if you can answer it.
When I describe this to people I always feel like theyre looking for specifics and I'm not giving enough detail.
Thanks!
Client initiates communication (Usually a HTTP GET request)
Server receives REQUEST-HEADER and parses the URL contained within.
Server does a lookup to see if any URL matches locally in a harddrive-folder. If the webserver handles virtual servers like a Microsoft IIS, then it will determin which folder to search after retrieving the "www.domain.com" part from the REQUEST header.
If web-document (HTML file) is found, then Server sends this back as RESPONSE + a HTTP status code (eg. 200 saying: found, this request went well, where as 404 is "didnt find that file")
Client (browser) receives RESPONSE and can now display it as it wants. If it contains a render engine, then it will search for patterns (HTML tags or whatever language) and then display it as such.
This is also called "stateless" as the server closes communication with client after the client has received everything from the reponse-stream.
Therefore the server cannot know if the client is still connected nor if its comming back later. Many servers does provide a session object using cookies or similar to track if its the same client that sends the next REQUEST and if so, allowing more "intelligent" server responses - such as seeking, transactions and logins.
How does the internet work?
HTTP Made Really Easy
The Canonical Document: RFC 2616
The client sends request headers to the server (finds the IP via DNS).
The server software (e.g. Apache) calls CGI if it needs to and prepares the response.
It sends headers back as well as the content.
I'm thinking about exploring the idea of having our client software run as a service on a high port and listen for simple http GET requests from 127.0.0.1. The theory is that I would be able to access this service via js from a web page that is served from my site.
1) User installs client software that installs itself as a service and waits for authenticated requests on 127.0.0.1:8080
2) When the user hits my home page js on the page makes an xhtml request to 127.0.0.1:8080 and asks for the status
3) The home page then makes another js request back to my web server sending the status that it received.
This would allow my users to upload/download and edit files on a USB attached device in real-time from a browser. Polling could be the fallback method which is close to what we do today.
Has anyone done this and what potential pitfalls are there? Will this even work?
I can't see any potential pitfalls. I do have a couple of points however.
1/ You probably want to make sure your service only accepts incoming connection from the local machine (127.0.0.1). Otherwise, anyone could look at your JavaScript and figure out that it's talking to [your-ip]:8080. They could then try that themselves from a remote site (security hole).
2/ I wouldn't use port 8080 as it's commonly used for other things (alternate HTTP servers, etc.). Make it configurable and choose a nice high random-type value.
3/ I'm not sure what you're trying to do with point 3 but I think you're trying to send the status back to the user. In which case, why wouldn't the JavaScript on your home page just get the status in a single session and output/update the HTML to be presented to the user? Your "another js request back to my web server" doesn't make sense to me.
You may not be able to do a xml http request to 127.0.0.1 as XMLHTTPRequest is usually limited to the same domain as the main content is being served from. I'm not sure if this restriction applies if the server is on the client's machine. That being said, you could still create a <script> tag that had the src pointing to 127.0.0.1, and have the web server return some Javascript to run. If you only need a simple response, this could work well.
I think it is much better for you to avoid implementation of application logic in JavaScript and html. Once user clicks button on a web page JavaScript should send request to your service and allow it do the rest of the work.
You could have problems with step 1 (Client installs itself) depending on your target user base.
You will need a customised install for each supported environment (Win2K, Vista, Linux, MAC OS 9.0/10.0 etc.).
If your user is on a locked down at work PC this simply wont be allowed.
To some users this might look distressingly similar to a trojan unless you explicitly point out you will be installing software that runs as a service.
You didnt mention an unistall procedure. Users resent "Adobe" like software which installs itself and provides no sensible un-install options
Ohterwise the approach is sound, and, there are are couple of commercial products out there that use exactly this approach!