Anyone know if it's possible to access the name of a jump link in c# code?
I'm doing some url Rewriting stuff and I'm thinking I might not be able to see that part of the URL.
So basically, my URL looks a little something like this:
http://www.mysite.com/Terms.aspx#Term1
And I want to access "Term1". I can't see it in the ServerVariables...
Any ideas?!?!?
THANKS!
The hash character is meant for client side navigation. Anything after the # is not submitted to the server.
From the wikipedia article:
The fragment identifier functions differently than the rest of the URI: namely, its processing is exclusively client-side with no participation from the server. When an agent (such as a Web browser) requests a resource from a Web server, the agent sends the URI to the server, but does not send the fragment.
Its technical name is Fragment Identifier
Perhaps System.Uri.Fragment? Or what is it you don't see?
Related
Part of a site I am working on at the moment requires Audio/Video previews.
These are server from a different server to the main site.
The Streaming URL is of the form:
www.myserver.com/Preview.aspx?e=I_AM_AN_ENCRYPTED_KEY
The Key is generated by the server that hosts the file, not the site on which the previews are actually displayed. It's kind of an API.
Part of the security to stop these previews being played anywhere except this website is supposed to check the domain which is requesting this, but it seems that HttpContext.Current.Request.UrlReferrer is NULL when requested from an HTML5 video/audio element.
Without posting the domain along with the Key to the API, is there any way that I can get the referring URL on the receiving server, server side?
EDIT:
To clarify:
There is a website with HTML5 elements which are directed to a URL on a different server, the URL and key is provided by this server (not the website)
When the API server receives a request to stream the preview it checks the Key (which basically tells it what to play) and also checks for the referring domain against a list of allowed domains.
Figured it out - in case anyone cares...
Simply replace:
ReferringDomain = HttpContext.Current.Request.UrlReferrer
with :
ReferringDomain = HttpContext.Current.Request.Headers("Referer")
Sorted! :)
I'm trying to create a web browser using Cocoa and Swift. I have an NSTextField where the user can enter the website he wants to open and a WebView where the page requested is displayed. So far, to improve the user experience, I'm checking if the website entered by the user starts with http:// and add it if it doesn't. Well, it works for most of the cases but not every time, for example when the user wants to open a local web page or something like about:blank. How can I check if adding http:// is necessary and if I should rather add https:// instead of http://?
You need to be more precise in your categorization of what the user typed in.
Here are some examples and expected reactions:
www.google.com: should be translated into http://www.google.com
ftp://www.foo.com: Should not be modified. Same goes to file:// (local)
Barrack Obama: Should probably run a search engine
about:settings: Should open an internal page
So after you figure out these rules with all their exceptions, you can use a regex to find out what should be done.
As for HTTP vs. HTTPS - if the site supports HTTPS, you'll get a redirect response (307 Internal Redirect, 301 Moved Permanently etc) if you go to the HTTP link. So for example, if you try to navigate to http://www.facebook.com, you'll receive a 307 that will redirect you to https://www.facebook.com. In other words, it's up to the site to tell the browser that it has HTTPS (unless of course you navigated to HTTPS to begin with).
A simple and fairly accurate approach would simply be to look for the presence of a different schema. If the string starts with [SomeText]: before any slashes are encountered, it is likely intended to indicate a different schema such as about:, mailto:, file: or ftp:.
If you do not see a non-http schema, try resolving the URL as an HTTP URL by prepending http://.
Is there a way to get the server url (ex: http://www.myapp.com:8080/applicationFolder) without having access to a Request object ?
I need the url at aplication_start and in some classes where the Request object with all the goodies is not available.
note: I know that getting the application folder can be done using
VirtualPathUtility.ToAbsolute("~/");
HttpContext.Current.Request is a static property that always returns the Request object currently executing for the session.
I think all you need a custom solution to know when first request is made after application starts, and then you can send any email you want.. this is the similar problem with solution here http://weblogs.asp.net/reganschroder/archive/2008/07/25/iis7-integrated-mode-request-is-not-available-in-this-context-exception-in-application-start.aspx this do first initialization check in BeginRequest event.
There can be many different addresses all pointing to the same ASP.NET website, like using IP address or name. There might be more than 1 DNS name pointing to the same ASP.NET application. Therefore, HttpApplication, the parent class of Global, does not know which URL a visitor will use. Even IIS doesn't know. Therefore, you have to wait for the first request and then check in the request what URL the visitor uses to access your site. Something like this:
string baseUrl = Context.Request.Url.GetLeftPart(UriPartial.Authority);
One has to use Context to get access to the Request during Global.Application_Start, because Global.Request is not initialised yet.
Is it possible to rewrite URL on the fly, only when a part of the server code has already been processed for the "raw" URL and it becomes clear the parameters must not be revealed to the user? Like, I want to proccess all the GET parameters in my page code on the server and create a tracking record in the database, then serve the user the page but change URL to parameterless in the browser.
I guess all the web.config referred module techniques won't work as they offer URL rewriting before request is passed to the page code on the server. But it comes in my case that I receive an ugly URL from google adwords clicks and I do like it tracked 'as is' in my database, and I do certainly not like it show to user in her brower's bar.
At the same time I would like to keep URL unchanged without applying the URL rewrite most of the time unless some particular parameter shows up in it (like ref=adwords) so that any paramter written by hand or posted back would be displayed in the address bar.
Is it possible to do so by any means?
Have you considered writing an ActionFilter that would (if your controller or method is decorated with it) intersect your initial request, do all the necessary processiong and then redirect back to the requested page only indicating, that processing has been done?
This would be my first thought.
In the current HTTP spec, the URL fragment (the part of the URL including and following the #) is not sent to the server in any way. However with the increased spread of AJAX, which uses the fragment to maintain some form of state, there are a lot of situations where it would be useful for the server to have knowledge of the URL fragment at request time.
For example, if you go to http://facebook.com, then click a user name in your stream, the URL will become http://faceboook.com/#!/username - to allow FB to update your page without reloading all of its bootstrap JS and HTML. However, if you were to reload this with your browser, the server would have no way of seeing the "#/!username" part of the URL, and therefore could not pre-render the content for you. This forces your browser to make an extra request once the client Javascript has loaded and parsed the fragment.
I am wondering if there have been any efforts or proposals towards creating a standard mechanism to achieve this.
For example, there could be a standard HTTP header, which would be sent with the value of the URL fragment - any server which cared about such things could then have access to it.
It seems like this would be a very useful thing for the web-application community as a whole, so I am surprised to not have heard anything proposed. Perhaps I missed it though.
Imho, the fragment identifier really is not a good place to store the state, it has been designed for something else.
That being said, http://www.jenitennison.com/blog/node/154 has a good discussion of the whole subject.
I found this proposal by Google to make Ajax pages crawlable, but it addresses a more constrained set of use cases. Specifically, it creates a way to replace the URL fragment with a URL parameter to obtain the same HTML output from the server as would be generated by a client visiting the equivalent URL with the fragment. However, such URLs are useless for actually running the Ajax apps, since they would necessitate a page reload every time.
Webkit Bug 24175 - URL Redirect Loses Fragment refers to Handling of fragment identifiers in redirected URLs which may be of interest.
A suggestion for a future version of HTTP may be to add an (optional)
Fragment header to the request, which holds the fragment identifier.
Even simpler may be to allow an HTTP request to contain a fragment
identifier.