I have a simple web server going on an Atmel embedded processor. It's a Cortex M4 and it's only running FreeRTOS as an OS; this is not a high powered processor.
I can have it [the Atmel processor] serve up a page by typing in Firefox:
192.168.0.200
This renders a page with drop down boxes and a submit button that enables me to pass data back to the server to control the hardware.
I am using the follwing kind of HTML. Please note, it looks slightly odd because it's in a C string:
"<form> \
<select name=\"group\"> \
<option value=\"10\">10</option> \
<option value=\"11\">11</option> \
<option value=\"12\">12</option> \
<option value=\"Broadcast\">255</option> \
</select> \
<input type=\"submit\" value=\"Submit\"> \
</form>"
You can see that, in its address bar, the browser then has something like:
192.168.0.200/?group=4
When the web server on the emebedded processor gets that message in, I can happily parse the line, extract a group number and act on it.
However, I have to send back another page to the browser when I get the
192.168.0.200/?group=4
message into the Atmel processor. Otherwise I get a timeout message. I can happily send the original page back again and it essentially works, but sending the page back resets the values of what the drop down boxes have changed to.
Is there a way of making the browser send a message that the server can parse, but not have to send out the full page again? I guess I'm needing to use something like a POST command, but I don't know how to do that from a web page. I should say that I am experienced in C, but have no HTML knowledge other than what I have learnt in the last few days, so it may be something easy that it completely eluding me from cramming in all this learning this week!
I don't want to/assume I can't use Javascript, because I have such a simple server I need to keep it as simple as possible.
Thanks!
Is there a way of making the browser send a message that the server can parse, but not have to send out the full page again?
Forget about the browser.
Have the server respond with a 204 No Content response instead of a 200 OK response.
If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.
I don't want to/assume I can't use Javascript, because I have such a simple server I need to keep it as simple as possible.
JavaScript runs client side. You don't need the server to do anything complicated to serve JS. You can even embed it in the HTML document.
You could use Ajax to solve your problem instead of a No Content response.
Related
In my html I'm using hidden value as :<input type="hidden" value="secure" name="first"> but the problem is when I see in browser console value is displaying .How to hide this?
The browser belongs to the visitor. You can't give the browser anything without giving it to the visitor as well.
If you don't want to visitor to have access to data, then never give it to the browser in the first place.
Keep the data on the server and send the browser a session token instead.
You can't. The whole point of a client/server based setup, like 'the web' is by definition, is that everything you transmit to the client can be read by any client.
If you need to secure data from the end user, keep it on the server side. There are a myriad of possible solutions for this, like sessions, cookies and preshared keys, to sync serverside storage with the client.
Title question asks it all, what's the process going on under there? Why do I have to use AJAX if I wanted to submit that form asynchrously?
It's due to the way HTTP was designed. Back then, JavaScript was not as ubiquitous and not as powerful as it is today.
As it is, when you POST data to a page (a path), you are issuing a request to a server. The server can then respond in a variety of manners. There is the simple "return some content", whether it be HTML, text, JSON, XML, etc. There is also the possibility for the server to return a redirect, sending you to a different location.
What AJAX does is simply to run this request in the background and hide the fact that data was submitted to the server and a response was returned from the user's perspective.
I want to make a turn based game (Something like Checkers) with the help of Servlets and jsp pages.I created a page that has a newGame button that redircet to the gamePage(It redirect the first into a Black.jsp and the other request will be redirected to Red.jsp).
My problem is ,how could I refresh the other jsp automaticaly if one of them changed.
Note:After the change in one of the jsp it redirect the request to servlet and servlet update the changed jsp graphics.but the other jsp stay inactive.I want to make it active.
Thank You
It sounds like what you need is Comet. Here's an overview of how it works.
http://www.ibm.com/developerworks/web/library/wa-cometjava/
Basically, the "other" user's browser will send a request to a servlet to get an update, but that request won't receive receive its response until the current player makes a move. This gets around the problem posed by the fact that, with traditional HTTP, the browser always has to be the one sending the request to the server, it can't be the other way around.
There are some variations on the technique. Now that you know the name, I'm sure you'll be able to find lots of useful information about it.
There's another technology called WebSocket which can also serve this purpose, but it requires additional capability built into the browser and, as of now, probably not all of your users will be using compatible browsers.
I have a simple RESTful web service and I wish to test the PUT method on a certain resource. I would like to do it in the most simple way using as few additional tools as possible.
For instance, testing the GET method of a resource is the peak of simplicity - just going to the resource URL in the browser. I understand that it is impossible to reach the same level of simplicity when testing a PUT method.
The following two assumptions should ease the task:
The request body is a json string prepared beforehand. Meaning, whatever is the solution to my problem it does not have to compose a json string from the user input - the user input is the final json string.
The REST engine I use (OpenRasta) understands certain URL decorators, which tell it what is the desired HTTP method. Hence I can issue a POST request, which would be treated as a PUT request inside the REST engine. This means, regular html form can be used to test the PUT action.
However, I wish the user to be able to enter the URL of the resource to be PUT to, which makes the task more complicated, but eases the testing.
Thanks to all the good samaritans out there in advance.
P.S.
I have neither PHP nor PERL installed, but I do have python. However, staying within the realm of javascript seems to be the simplest approach, if possible. My OS is Windows, if that matters.
I'd suggest using the Poster add-on for Firefox. You can find it over here.
As well as providing a means to inspect HTTP requests coming from desktop and web applications, Fiddler allows you to create arbitrary HTTP requests (as well as resend ones that were previously sent by an application).
It is browser-agnostic.
I use the RESTClient firefox plugin (you can not use an URL for the message body but at least you can save your request) but also would recommend curl on the command line.
Maybe you should also have a look at this SO question.
Is there any way to send data from one HTML page to another using basic HTML without using JavaScript and PHP?
It's easy to "send" data:
Send
but there is no way for the receiving page to parse it without a server-side application or JavaScript. (Or Flash, or a Java applet, or an ActiveX control....)
html only purpose is to show content. It is not designed for getting and passing data. you need server side script to do that.
Good answers. Pekka and Andre really nailed it.
In order to pass data from HTML form fields to your web application:
1) You can manually build a link with query string variables (basically Pekka's example)
Submit
2) Or, to retrieve data typed in by the user (which is typically what you want), you can use the GET method
<form action="signup.pl" method="get">
Name: <input type="text" name="name" />
<input type="submit" />
</form>
Either way, you end up with a post to the web server with the same URL (provided the user typed "john"):
http://www.mycatwebsite.com/signup.pl?name=john
(or you can use POST instead of GET, but then query string variables don't show up in the URL)
But in order to read and process it, as already mentioned, you need a server side programming language.
Even the first dynamic websites back in the 90's used CGI Perl scripts, or even ANSI C, to process data. Here's a simple Perl example:
HTML Forms POST, GET
Now of course there are many web application languages (and frameworks) to choose from, such as PHP, Java, ASP.NET, Ruby, Python, etc. But they all adhere to the CGI convention of passing data back and forth (CGI Request/HTML response) between the web server (Apache, IIS) and the web site.
Common Gateway Interface
Dynamic website
You can prompt the user to enter data with a <form>, and you can add GET-query-parameters to your URL (index.php?foo=bar). But to work with the received data, you will need to use a programming language.
You can send data but can't process sent data. For it you must use PHP, javascript or something similar...