I'm writing a small web-server to generate a web interface for a project. The environment I'm using is LabVIEW, because it's what I'm most familiar with.
The problem is that when I send it GET / HTTP/1.1 with PuTTY, it returns
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
<html>
Content-Length: 52
<head>
foo
</head>
<body>
bar
</body>
</html>
LabVIEW says the string being sent out is:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 52
<html>
<head>
foo
</head>
<body>
bar
</body>
</html>
When opening the HTML file in the web browser directly, it opens properly. When requesting it from the server program, the page doesn't finish loading, and never displays anything. I'm fairly sure the HTML is valid.
How can I debug this better? Am I missing a setting in PuTTY? Do I need to talk to National Instruments?
First, note that this isn't valid HTTP as there's supposed to be a blank line after the last header; that might be the problem with viewing in a browser.
Secondly, I bet you're not printing all the text at once, but rather printing the headers through some channel separate from the HTML, so they can get interleaved. Make sure you're using the same pipe to send all the data.
You could try to connect using windows telnet from the command line. Might possibly give you another clue.
Also, try to turn on logging in PuTTY and have a look at the logfile with a HEX-Editor. Maybe there are some "weird" characters in between which confuse the output - you never know.
And: Check that you are connecting with PuTTY using the "Raw" connection type and not "Telnet".
Related
Environment:
Windows 10, Visual Studio 2017.
Skills
C++ professional;
HTTP newbie;
Problem:
I try to access the replied html text-string from iextrading.com/apps/stocks/FDX but does not succeed.
Tried Winsock functions
I have try some functions gethostbyname(), htons(), connect(), send() and recv() and it works well e.g. for the site "google.com" the post "GET / HTTP/1.1\r\nHost: www.google.com\r\n\r\n" works.
While for site "iextrading.com", the post "GET / HTTP/1.1\r\nHost: www.iextrading.com\r\n\r\n" return:
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
And if I try get "GET / HTTP/1.1\r\nHost: www.iextrading.com/apps/stocks/FDX\r\n\r\n" it say bad request.
But in any web-browser i see "iextrading.com" or "iextrading.com/apps/stocks/FDX" works fine.
Desired:
Is there a generic function to simply return same html-text as a web-browser does, or how to read specific this web-address "iextrading.com/apps/stocks/FDX" ?
The host name is just that, the host name. If you want to GET "http://iextrading.com/apps/stocks/FDX" then the request URI is "/apps/stocks/FDX", not "/".
I need help with how to integrate image in HTML page and send it to mail.
I saw few mail on stack exchange and online but were of no help as they were very high level description and resolution.
I tried below but no luck. Anyone who might be able to help as what went wrong and how can i create a script or send mail, i tried below:
From: test.mail#server.com
To: atul.path#server.com
Subject: HTML Messages with Embedded Pic in Signature
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="multipart_related_boundary"
--multipart_related_boundary
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<img alt="Image of alok" src="cid:0123456789">
</body>
</html>
--multipart_related_boundary
Content-Type: image/jpeg; name="alok.jpeg"
Content-Transfer-Encoding: base64
Content-Location: sig.png
Content-ID: <0123456789>
Content-Disposition: inline; filename="alok.jpeg"
Qk3m2QAAAAAAADYAAAA/v7+/////////////////////v7++vr67e3t2NjYHR0dAAAAAAAAAQEBAgICAwMDBAQEBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBDREAMD/AZHABQUFAang// ) | sendmail -t
I suppose you can use the Outlook object model to get the job done.
You need to add an attachment using the Add method of the Attachments class. Use the default value - olByValue (the attachment is a copy of the original file and can be accessed even if the original file is removed).
Then set the PR_ATTACH_CONTENT_ID property (DASL name is http://schemas.microsoft.com/mapi/proptag/0x3712001F) using the SetProperty of the PropertyAccessor class. The Attachment class provides a corresponding property to get an instance of the PropertyAccessor class. You can use any value. Be aware, the value will be used to refer to the attached item in the HTML markup in the following format:
<img src="cid:tatata"/>
where tatata is the value of the PR_ATTACH_CONTENT_ID property.
Finally, you may find the Getting Started with VBA in Outlook 2010 article helpful.
I'm writing a web server in C#, just for the fun of it, and I am able to serve basic text files to my browser. However, when serving up an image (say, image.png), all browsers that I test my server on (IE, Firefox, and Chrome) show some kind of placeholder thumbnail for the image, as if the image is corrupted or invalid.
The response that I am sending to the browser looks like
HTTP/1.0 200 Ok
Content-Type: image/png
Content-Length: 14580053
{image data here}
Am I using the correct HTTP headers? Or, if I am, why else would browsers not accept the image?
Ah, figured it out... my code forgot to add an extra \n before the response body. It wasn't a problem with the headers at all, just incorrect response syntax.
I am running Windows 7, 64 bit. I have recently updated my OS to install the latest updates. Since then, most PDF documents have stopped rendering in my program. My program wants to display PDF documents in a separate iFrame. I do this by getting the URL of the PDF document and setting window.frames['docview'].location = url; In most cases, the iframe view remains blank (or clears if something was shown there previously). If I take that same URL and open it in a new tab or window, it renders fine.
When it fails to render in my iframe, I see the following message in the Chrome console:
Resource interpreted as Document but transferred with MIME type application/pdf.
Firefox does not offer a message of any kind in its error console, or on the FireBug console.
I have no control over the source of the PDF files, so I cannot change their header information.
Oddly, some files do load correctly.
Looking at the network requests in Chrome, for a document that fails to load I see (for example):
Request URL:http://es.csiro.au/pubs/paradis_mdm03.pdf
Request Method:GET
Status Code:200 OK
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Host:es.csiro.au
Referer:http://querium.fxpal.net:8080/querium/ui/query?searcherId=2&compact=true&sidx=rank&topicId=2&queryId=1&lastEventId=1490893682130103&highlight=undefined
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
Response Headers
Accept-Ranges:bytes
Connection:Keep-Alive
Content-Length:71764
Content-Type:application/pdf
Date:Tue, 06 Sep 2011 04:59:26 GMT
ETag:"1f48c8-11854-43e4ee482ef40"
Keep-Alive:timeout=15, max=100
Last-Modified:Wed, 07 Nov 2007 04:07:49 GMT
Server:Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
When opened from a separate tab (where the document does render), I get the following:
Request URL:http://es.csiro.au/pubs/paradis_mdm03.pdf
Request Method:GET
Status Code:304 Not Modified
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:es.csiro.au
If-Modified-Since:Wed, 07 Nov 2007 04:07:49 GMT
If-None-Match:"1f48c8-11854-43e4ee482ef40"
Range:bytes=0-71763
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
Response Headers
Connection:Keep-Alive
Date:Tue, 06 Sep 2011 05:07:15 GMT
ETag:"1f48c8-11854-43e4ee482ef40"
Keep-Alive:timeout=15, max=100
Server:Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
One odd things is the difference in status, but maybe the server is being smart or there is some funny interaction with the cache. Who knows.
Any help would be greatly appreciated.
Gene
EDITED: 9/6/2011
When I removed the tag
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
from the <head> element of my HTML page, many (but not all) of the PDFs started rendering properly. This was an apparent duplicate of another meta tag in the header:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
Does this help shed any light on the potential problem?
Instead of setting the src attribute of the iframe to the PDF, set it to a wrapper HTML-file, which contains a simple div:
<!DOCTYPE html>
<html style="height:100%;">
<head>
</head>
<body style="height:100%;">
<div id="divContents" style="height:100%;"></div>
</body>
</html>
In javascript the contents of the div is set to an object element. Unfortunately slightly different versions are needed to work reliable on all browsers (tested on IE, Firefox and Chrome):
(I simplified the retrieval of the divContents element and the browser detection)
var embed = '<object type="application/pdf" width="100%" height="100%"';
if (msie) {
embed += '><param name="src" value="' + pdf + '"/>';
}
else if (chrome) {
embed += ' src="' + pdf + '">';
}
else {
embed += ' data="' + pdf + '">';
}
embed += '</object>';
$("#divContents").html(embed);
UPDATED
I've finally found the actual cause of the failure in Chrome: It's the Accept-Ranges:bytes field, without it Chrome will not work when the data attribute is used.
So if your server is capable of supporting the Accept-Ranges field, you should make sure it is returned to the client. In that case you can use the pdfobject library to display the PDF in a frame or div.
If not, you can use the code above to display the PDF in a frame or div.
In the past a few issues has been reported with pdf loaded in iframes, both for Firefox and Chrome (in particular when headers like Content-Type and Content-Disposition are not properly set).
Probably you should use an <object> tag to embed a pdf in your page, instead of an iframe, but an easier solution is the pdfobject library. To verify this works, you can browse this jsfiddle with Chrome and Firefox.
Moreover, you can use a proxy script in your server to stream the PDFs: your page will point to the proxy script and pass an identifier (so that it won't be hacked easily) and the script will download and send to the browser the matching pdf with the proper headers.
Finally a note about the different status codes: in the first response the server has sent to the browser the Last-Modified and the ETag that contains a timestamp and a hash of the file; thus the browser, in the second request ask for the resourse only
If-Modified-Since:Wed, 07 Nov 2007 04:07:49 GMT
If-None-Match:"1f48c8-11854-43e4ee482ef40"
Since the resource has not be changed, the second response is a 304.
One of the request parameters in an http request made by the client contains Japanese characters. If I make this request in Firefox and look at the parameter as soon as it reaches the server by debugging in Eclipse, the characters look fine. If I do the same request using IE 8, the characters get garbled when I look at them at the same point in the server code (they are fine in both browsers, though). I have examined the POST requests made by both browsers, and they both pass the same sequence of characters, which is:
%2C%E3%81%9D%E3%81%AE%E4%BB%96
I am therefore thinking that this has to do with the encoding. If I look at the HTTP headers of the request, I notice the following differences. In IE:
Content-Type: application/x-www-form-urlencoded
Accept: */*
In Firefox:
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
I'm thinking that the IE 8 header doesn't state the UTF-8 encoding explicitly, even though it's specified in the meta tag of the HTML document. I am not sure if this is the problem. I would appreciate any help, and please do let me know if you need more information.
Make sure the page that contains the form has UTF-8 as charset. In IE's case, the best thing to make sure of this is by sending a HTTP header ('Content-Type: text/html; charset=utf-8') and adding a meta http-equiv tag with the content type/charset to your html (I've seen this actually matter, even when the appropriate header was sent).
Second, your form can also specify the content type:
<form enctype="application/x-www-form-urlencoded; charset=utf-8>