I'm building a web app (well at least one page on it) that shows the results of pings to different IPs.
I have no probs on Go displaying them on an HTML page. The simple thing I can't do (and I read so many tuto/threads that I'm lost and don't know what to do....) is to create a button "Refresh" that could just call back the "pingip" function i created in Go file.
Anyone has a concrete/"easy" example on how I could do this?
Assuming you have a HTTP Handler for your Go program, which is what is serving the page - then you can have the button simply do a window.reload() through JavaScript, which will reload the page in the browser and re-invoke the Go script.
If you want this to happen without a reload, then you'd have to create a different HTTP Route and use AJAX (look up the fetch method in JavaScript), get the results over the network (maybe as JSON) and then update the data in the frontend.
I have Apache set up through XAMPP on a Windows 7 x64 system, and for some reason it isn't serving any error pages. I have
ErrorDocument 404 /404.html
set up in both httpd.conf and .htaccess in my webroot dir, but whenever I purposefully request a page that doesn't exist to test it, Apache returns nothing at all - not my 404 error page or the default Apache 404 page, just a blank page, with nothing in it at all. I think this is one of the "soft 404" problems, because the Apache logs and Chrome both say that the request for the non-existent page resulted in a 200 OK response, but I have no idea how to fix it, because I'm not getting anything from the server. The logs don't tell me anything, and my searches on Google / etc. haven't resulted in any solutions for the problem I'm facing. Could it be that because I'm using a PHP semi-redirect script to route all requests that would have gone to http://localhost/* to http://localhost/testing/ that errors are being generated and then interpreted as not errors? For example, a request for http://localhost/foo.html will redirect to http://localhost/testing/ (not /testing/foo.html, but this is expected behavior), but a request for http://locahost/testing/foo.html (which doesn't exist) will result in a empty page and a 200 OK from Apache. If I request a page that exists though I usually get what I want, but sometimes Apache will also send back nothing at all for a PHP script that exists - for example I'm playing with sNews, and a request for index.php (http://localhost/testing/snews/index.php) will result in a blank page, even when the page has HTML that should display even if nothing is parsed / inserted.
Other then this, PHP, MySQL, Perl, and almost everything else works perfectly. A normal page will load if it exists, and the only problems that exist are those explained above, and this is really annoying because it's preventing me from finishing a certain project. Any help at all is greatly appreciated.
Just to close this question despite how long it's been since it was relevant:
Problem was Apache and PHP had conflicting directives - PHP would route all requests for / to /testing and Apache would look for error pages in / but get redirected by PHP and therefore fail.
hey guys! why is it that everytime i click something on my website and try to go back one page, it says "Confirm Form Submission". Im running a local server. This is in contrast to other websites like facebook where i can go back a page without that annoying message asking me to refresh the page.
Nice Explanation indeed :
Because of the sloppy coding practices of web developers browsers were forced to add this message. the scenario is as follows:
1) user fills in form and submits (posts form)
2) the server process the post data and responds with a new page (confirm) marked as not cacheable
3) the user navigates to a new page.
4) the user press back:
for the the browser to display the page in step 2, because its marked no-cache, it must request it from the server, in other words do the repost of the data (do step 1). here is were the sloppy coding came in, if this was an credit card charge, and repost detection was not on the server, the card is charged twice. this was (is) so common a problem, that the browsers had to detect this and warn the users.
the best fix is in step two, the server sends a redirect to the confirm page. then when the user accesses the confirm via history or back, its a get request, not a post request and will not show the warning.
source : http://forums.asp.net/p/1553589/3814773.aspx
okay nevermind people. apparently i was using POST method everywhere. changing it to GET solves the problem. I think it has something to do with caching..
Google chrome sends multiple requests to fetch a page, and that's -apparently- not a bug, but a feature. And we as developers just have to deal with it.
As far as I could dig out in five minutes, chrome does that just to make the surfing faster, so if one connection gets lost, the second will take over.
I guess if the website is well developed, then it's functionality won't break by this, because multiple requests are just not new.
But I'm just not sure if I have accounted for all the situations this feature can produce.
Would there be any special situations? Any best practices to deal with them?
Update 1: Now I see why my bank's page throws an error when I open the page with chrome! It says: "Only one window of the browser should be open." That's their solution to security threats?!!
Your best bet is to follow standard web development best practises: don't change application state as a result of a GET call.
If you're worried I recommend updating your data layer unit tests for GET calls to be duplicated & ensure they return the same data.
(I'm not seeing this behaviour with Chrome 8.0.552.224, by the way, is very new?)
I saw the subjected behavior while writing a server application and found that earlier answers are probably not true.
Chrome distributes a single request into multiple http ones to fetch resources in parallel. In this case, it is an image which it fetches as a separate http get.
I have attached screen shot of packet capture through wireshark.
It is for a simple get request to port 8080 for which the server returns a hello message.
Chrome sends the second get request for obtaining favorite icon which you see on top of every tab opened. It is NOT a second get to cater time out or any such thing.
It should be considered another element that differs across browsers. However, doing things in multiple http requests in parallel is kind of a standard thing in browsers as of 2018.
Here is a reference question that i found latter
Chrome sends two requests SO
Chrome issue on google code
It also can be caused by link tags with empty href attributes, at least in Chromium (v41). For example, each of the following line will generate an additional query on the page :
<link rel="shortcut icon" href="" />
<link rel="icon" type="image/x-icon" href="" />
<link rel="icon" type="image/png" href="" />
It seams that looking for empty attributes in the page is a good starting point, either href or src.
This behavior can be caused by SRC='' or SRC='#' in IMG or (as in my case) IFRAME tag. Replacing '#' with 'about:blank" has fixed the problem.
Here http://forums.mozillazine.org/viewtopic.php?f=7&t=1816755 they say that SCRIPT tags can be the issue as well.
My observation of this characteristic (bug/feature/whatever) occurs when I am typing in a URL and the Autocomplete lands on a match while still typing in the URL.
Chrome takes that match and fetches the page, I assume for the caching benefits that would occur when loading the page yourself....
I have just implemented a single-use Guid token (asp.net/TSQL) which is generated when the first form in a series of two (+confirmation page) is generated. The Token is recorded as "pending" in the DB when it is generated. The Guid token accompanies posts as a hidden field, and is finally marked as closed when the user operation is completed (payment). This mechanism does work, and prevents any of the forms being resubmitted after the payment is made. However, I see 2 or 3 (!?) additional tokens generated by additional requests quickly one after the other. The first request is what ends up in front of the user (localhost - so ie., me), where the generated content ends up for the other two requests I have no idea. I wondered initially why Page_Load handlers were firing mutliple times for one page impression, so I tried a flag in Http.Context.Current - but found to my dismay, that the subsequent requests come in on the same URL but with no post data, and empty Http.Context.Current arrays - ie., completely (for practical purposes) seperate http requests. How to handle this? Some sort of token and logic to refuse subsequent page body content requests while the first is still processing? I guess this could take place as a global context?
This only happens when I enable "webug" extension (which is a FirePHP replacement for chrome). If I disable the extension, server only gets one request.
I just want to update on this one. I've encountered the same problem but on css style.
I've looked at all my src, href, script tag and none of them had an empty string. The offending entry was this:
<div class="Picture" style="background-image: url('');"> </div>
Make sure you also check your styles for empty url string
I was having this problem, but none of the solutions here were the issue. For me, it was caused by the APNG extension in Chrome (support for animated PNGs). Once I disabled that extension, I no longer saw double requests for images in the browser. I should note that regardless of whether the page was outputting a PNG image, disabling this extension fixed the issue (i.e., APNG seems to cause the issue for images regardless of image type, they don't have to be PNG).
I had many other extensions as well (such as "Web Developer" which many have suggested is the issue), and those were not the problem. Disabling them did not fix the issue. I'm also running in Developer Mode and that didn't make a difference for me at all.
In my case, it was Chrome (v65) making a second GET /favicon.ico, even though the response was text/plain thus clearly no <link in there referring the icon. It stopped doing that after I replied with a 404.
Firefox (v59) was sending 2 requests for favicon; again it stopped doing this after the 404.
I'm having the same bug. And like the previous answer this issue is because I've installed the Validator chrome extension
Once disable the extension, works normally.
In my case I have enpoint (json) data to a different server and browser make first an empty request(Request Method:OPTIONS) to check if a endpoint accept requests from my server, Same-origin policy. Also goot to know is a Angular 1 App.
In conclusion I make requests from localhost to a online fake json data.
I had empty tcp packet sent by Chrome to my simple server before normal html GET query and /favicon after. Favicon wasn`t a problem but empty tcp was, since my server was waiting either for data or for connection to be finished. It had no data and wouldn't release connection for 2 minutes. So thread was hanging for 2 minutes.
Jrummell's Link in a comment to original post helped me. It says empty tcp packets could be caused by "Predict network actions to improve page load performance" setting. I tried turning off prediction settings one by one and it worked. In chrome version 73.0.3683.86 (Official Build) (64-bit) this behavior was caused by chrome setting "Use a prediction service to load pages more quickly" turned on.
So in chrome~73 you can try going to setting -> advanced -> privacy and security -> Use a prediction service to load pages more quickly and turn it OFF.
It could be situation when Chrome send in start the request with method OPTIONS and only the second is real request with method GET. Usually in code we deal only with GET (or POST/PUT/DELETE..) but not with OPTIONS. Check if the first request has method OPTIONS.
Not sure if I really am on the right forum, but if not, just tell me. I have a page that is coded in ASP (not .net) which is used to send email. We are currently having a problem in which the page seem to be sent twice sometime. Upon checking, we found out that those who have this problem are coming from big organisation, so it was suggested that their server might cache the file for some reason.
I would like to know, is there a way in HTML (or ASP ) to prevent that from happening ? Or is it in IIS that we must set this up ?
EDIT : I forgot to mention is that sometime, the time between the two mails can be in hours, not mere seconds
Thanks,
I don't see any cache problem here.
The only solution i see is to store somewhere server side(db, file system) the list of emails sent and check the list before send them.
With this approach, you will be sure to send just one mail to the specified address avoiding double submit or other possible problem.
I do not see how this could have anything to do with caching. After all, a cached page contains the generated html, and thus it would not trigger another execution of the code that sends the email.
However, my best guess is that it has to do with users that refresh the page. To avoid this, you could implement the post/redirect pattern, where after sending the mail you redirect to another page (or the same page but with different form parameters). This way the user can refresh the page as many times as he/she wants without triggering another email being sent.
If your problem is caching, there's really nothing you can do to keep an organization from caching it.
You can try to add this code to see if it makes a difference:
Response.Expires = 0
Response.Expiresabsolute = Now() - 1
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "no-cache"
If this doesn't work, you may need to contact that organization's IT department and ask them to add a caching exception for your page/site.