I'm using the Gitlab API that needs part of the path URL encoded when fetching files, but for some reason Dhall double-encodes my URL (example uses just google.com to minimize):
Welcome to the Dhall v1.41.1 REPL! Type :help for more information.
⊢ https://google.com/hello%2Fworld
Error: Remote file not found
HTTP status code: 404
URL: https://google.com/hello%252Fworld
According to https://docs.dhall-lang.org/howtos/migrations/Deprecation-of-quoted-paths-in-URLs.html it should indeed work with the above example, unless I'm misunderstanding something.
Is this a bug?
Related
Not FoundThe requested resource was not found on this server.
404 means the requested resource could not be found.
This means the provided URL is not valid or does not point to a file.
Maybe you can provide a little bit more context.
A list of HTTP status codes
When you're writing the manifest.json file, you have to specify matches for your content scripts. The http and https work fine, but if I try to include chrome://*/* or any variant of it, I get an error that I'm attempting to use an invalid scheme for my matches.
Is it not allowed?
By default you cannot run on a chrome:// url page.
However, there is an option in chrome://flags/#extensions-on-chrome-urls:
Extensions on chrome:// URLs (Mac, Windows, Linux, Chrome OS, Android)
Enables running extensions on chrome:// URLs, where extensions explicitly request this permission.
You still have to specify pages that your extension can run on and wildcards are not accepted - so you have to specify the full URL eg chrome://extensions/
The authorized schemes for matches are http, https, file, ftp.
Therefore, chrome is not a valid scheme.
Yes, it is not allowed. You can't link to them from hrefs on a webpage either.
I originally asked the following question, to get some anwsers on how to handle special characters in an URL (GET) request for my Web Api:
Web Api 2 routing issue with special characters in URL
Encoding was obviously the way to go. But in order to get everything working, i had to do a pretty nasty workaround. And now, Im' at the point where i don't really understand why my workaround had to be done in the first place. So, the following is my setup:
A client can call my Web Api 2, Hosted on iis 8.5, by a get request containing an email in the URL. The most extreme example would be the following email:
!$%&'*+-/=?^_`{}|~#test.com
And yes, that sucker is a valid email, which therefore the API has to support. The URL pattern is as follows:
.../api/permissions/{email}/{brand}/
So a get request would be something along the lines of this:
.../api/permissions/#!$%&'*+-/=?^_`{}|~#test.com/economy
As the marked answer to my other question suggests, encoding this url is obviously a necessity. But this left me with a couple of other issues, such as "double escape of characters not allowed", and some specific "404 - not found" (routing could not pass the url). This i could mange to handle with the following settings for iis:
<system.web>
...
<httpRuntime requestPathInvalidCharacters=""/>
</system.web>
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true"/>
</security>
...
</system.webServer>
Now i was able to call my method with those pesky special characters, and everything was fine. But i hit another bump. The email specified above, #!$%&'*+-/=?^_`{}|~#test.com, resulted in a 404 - not found. An actual 404 - not found. The routing couldn't handle the request url:
[Route("{email}/{brand}"]
As I understand it, the iis decodes the request url, passes it on to the iis request pipeline, it is then picked up by the web api and run through the http message handlers before hitting the controller. In the controller, i could clearly see that the email part of the url was no longer encoded (provided i used a simple encoded email. the encoded email "#!$%&'*+-/=?^_`{}|~#test.com" still responded 404). I quickly figured, that the routing probably couldn't handle the fragmentation inside the url path, as the iis passes on a decoded url to the web api. So i had to get the url reencoded in the iis before handed on to the web api.
This i was able to make a workaround for, by using Url ReWrite. It reencoded that specific part of the url containing the email, and now the routing was handled properly with the special-character-email. The expected method was hit, and i could just decode the encoded email. To briefly sum up, this was the flow:
Request flow
Now, we have set up a LogMessageHandler which logs incoming requests and outgoing responses. When the logger logs the request.RequestUri, it is clear that the email is double encoded. But when the controller method is hit, it is only encoded once! So.. My question is, why do i have to reencode the URL in the iis for the routing to handle the request properly, when the url is already automatically encoded (and decoded again before hitting the controller)? Is this something i can configure? Can i somehow extend the scope of which the URL is encoded, all the way to the controller??
Regards
Frederik
Does anyone know what this message means (or when it raises)?
CFURLCopyResourcePropertyForKey failed because it was passed this URL which has no scheme
The scheme in a URL is what appears before the first colon. For example, the scheme for the URL to this web page is http. You are probably passing an incorrect URL into the function. Set a breakpoint to see what you are passing in or log the URL.
I have been looking at the html5 boilerplate and noticed that the jquery include url starts with a double slash. The url is //ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js
Why is the http: missing?
I hate answering with a link but this explains it - http://paulirish.com/2010/the-protocol-relative-url/
Using a protocol relative URL like "//mydomain/myresource" will ensure that the content will be served via the same scheme as the hosting page. It can make testing a bit more awkward if you ever use FILE:// and then some remote locations as they will obviously resolve back to FILE. Never the less it does resolve the mixed insecure/secure content messages you can cause by not using it.
So that if the .html is accessed via HTTPS; the page will not have any unsecured script.