I'm trying to submit a postscript print job directly to printer on port 9100. I tried submitting a form directly to the IP and port, but it includes a lot of header information which obviously messes it up.
Is there a way to do this with jQuery or AJAX (or some other term I don't know about)?
You can't do it with Javascript, it'll only do HTTP requests (e.g. POST/GET), which means you get the full HTTP headers included.
Once WebSockets get more widespread, you could use those and send arbitrary data without the HTTP overhead/payload, but at present, that's only in 'bleeding edge' browsers.
This means you're stuck using a Flash or Java applet at present.
You can create a proxy php script which will accept your POST data from the form, format this data and send it to the printer
If you'd like to submit data to this script in background - please see my answer to the following post:
JavaScript: How do I create JSONP?
Related
Many places have said that only elements with a name attribute go to the server on page change, and only the element name and its value attribute's value travel between client & server. Is this a PHP feature or is it also present in other scripting languages? For example, is this the case with Node.js, or any of its popular server frameworks like express or grunt? Also, are there ways to send other elements or attributes to the server?
I know that AJAX can cause pretty much anything to go to the server, but this is usually asynchronous, and even when it isn't the info doesn't usually go to the server right when the page is sent. If you have any relevant info on AJAX, though, please share it.
When you give an element a name attribute, the browser will send the form data in the body of the request (if using POST) or in the query string (if using GET). This happens no matter what language or framework you use.
name is the only attribute that does this - it will not work with an id - but you can also do this with AJAX, by passing a querystring to XMLHttpRequest.send (if you're using jQuery, read up on jQuery.post). Requests via AJAX are, to the server, identical to requests from the client. If you send data in an AJAX POST request, it will be identical to a request via an equivalent form to the server. This is the same whether you're using PHP, Node.js, or any other web framework.
Helpful references:
http://en.wikipedia.org/wiki/POST_(HTTP)
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Sending_and_retrieving_form_data
the url is input by end users as string on my page, so may point to any domains.
JavaScript in current page needs to sniff the url, verify whether it's still valid, and return the types as image, or video, or audio, even considering html5 video audio tag and existent flash embed. And No need to wait for the complete file transfer.
Can someone help, from concept? thanks very much.
i'm aware the cross domain problem on ajax. So no idea on basic how-to.
If what you're asking, is:
Given any URL -> lookup given URL using a javascript ajax request, and determine if it is a video/audio/image - then, once detected, use the URL accordingly, then you can do something like this:
jQuery and AJAX response header
However, you'll not be able to make a request using client-side JavaScript to another domain, as it will require a cross-domain request (where your alternatives are JsonP, or weird headers in the response).
You're better off passing the URL to your own server, and performing the logic there (Via some kind of server-side web request) and passing a payload back to the client, with the required information in JSON or something - e.g.
{payload: 'video'}
Old question, but I recently wrote a utility that might help you out. It's a CORS-enabled MIME-type checker. See the API doc at lecoq.herokuapp.com
Use it like so: example
I'm trying to load a page differently if it is a post or a get, and seems like jQuery would have something so I could do
if (isPost())
{
// do something if this page was a post
}
I'm showing/hiding something based on the request type and want to do it specifically with javascript. I can easily do it with the framework I'm using, but don't want to.
The problem here is that you are confusing client-side with server-side.
GET, POST, PUT, DELETE, etc are all HTTP 'methods' that are sent to a server from the client (e.g.: the browser). The server then responds with the appropriate HTTP response, normally in the form of content that contains HTML.
POST/GET/etc have no context at the client side outside of dictating how a request should be sent to the server.
Think of the browser being your postal mailbox and POST/GET/etc being the method it was delivered. When someone sends you a piece of mail, they specify the method, such as first-class mail, overnight express, or same-day delivery. The Post Office handles the mail based on how it was received and sends the mail using the appropriate action. When you pick up your mail in the mailbox, you don't know if it got there via standard mail, overnight express, or same-day delivery. The only way you would know is any information that is on the envelope itself.
The solution to your problem would would follow this same principal. To resolve it, what you will need to do is include a hidden value that jQuery can pull in, either in the query-string, a special element, or as a hidden textbox that contains the HTTP method used to get the page.
This requires that server-side code be changed accordingly to push that information back to the client.
Hope that helps clear it up a bit.
i don't know if this is really possible in javascript. But you can check if there is a query string which is GET in the URL
if (location.search.length > 1) {
// your code.
}
location.search returns the query string in the URL
http://example.com/index.html?id=1&value=3
in this case location.search will be ?id=1&value=3 including the question mark.
so if it is present then you have a GET
Is it possible HTTP Accept headers using only javascript? I know using PHP I would do something like this $_SERVER['HTTP_ACCEPT'], but as far as I can tell javascript doesn't have this.
Perhaps I could do something with an XmlHttpRequest?
Any help would be awesome!
Thanks,
Mike
RE: "The headers sent to the server."
You could echo them back out in the server's response, and get them that way.
IE.) On a web-page you could make a hidden form field with the value, or pop the value into the javascript that gets emited from the page.
From a web service, you could include the value of the incoming header in part of the outgoing XML or JSON.
If you're using XmlHttpRequest, you could send a header back to the client with this value.
Possibilities are endless.
I'm dubious of why this would ever be useful though. The client should know what it's expecting before it requests it.
Are you looking for headers sent from the server or to?
If you're using Firefox and want to look at or alter headers going from the browser to the server, you might look at the sources for the Modify Headers plugin. It's not pure javascript, but it may help shake something loose.
i am using gwt.
i need to check some input data.
all checking functions are located in PHP server check.php
i am not using javascript checking executed from locally.
all i am doing is to send user input to server by ajax and validate in that place
and error message comes from server to client's gwt widget.
is it best approach??
i can do all checking from locally.but not doing.because server side is importent.
all checks must be resides in server so i am doing all checking from server.
if i do check locally and serverside two times ,then will it be best approach??
What you'll want to do is:
Use this account the next time you come back, or any of the others you've created, instead of creating an account each time you come to the site. Avoid this mess.
Create a .php page that accepts JSON-encoded data that you'd like to verify, and respond with some text like "OK" if it's valid. (I'm no PHP expert, but I'm sure there are plenty of them here)
Use GWT's RequestBuilder to send this data to the .php page, and call the RequestCallback's Response's getText() method. Check if the text is "OK" -- if so, the result is valid!
If you need more detail on any of the specifics, just let me know and I'll edit to clear things up.
Generally I agree with Jason (especially the with the first point :D).
I'd like to add that you should do validation on the client side first. Why? Because it allows you to weed out some obviously wrong inputs => less load on the server. But never accept the values from the client, just because your JS code said so - the general rule is to never trust the client side (because, well, it's the client side and the client can change the way your code works).
So in summary, I usually take these steps in my apps, they offer security and lower the load on your server, but may require a bit more work to write and maintain (especially if your client side and server side use different languages):
Validate input client side. If it doesn't pass, don't bother sending it to the server, just show an appropriate message.
If it does pass, send it to the server, but you must rerun the validation on the server side too.
If the server side validations report an error, send it back in some form (JSON with the error message and/or error code, set a HTTP response code, etc).