Currently Redoc includes the host URL in my API endpoint which I do not want it to do.
I tried several ways to hide it and only show the base path and endpoint in Redoc docs, but nothing seems to work.
Current behaviour - http://localhost:8000/v1/abc
Expected behaviour - /v1/abc
I do not want Redoc to add the host.
I tried passing an empty url in the servers attribute in my OpenAPI file, hide-hostname in Redoc options and other various ways like only passing a "/" in the url, but it always adds the security scheme or browser URL if nothing is provided.
I'm working with an API that doesn't yet have CORS setup. So, instead of waiting until that's setup, I thought I could use fiddler to add the Access-Control-Allow-Origin header to the responses coming from the server. I haven't used fiddler for a while and can't figure out how to add headers to the response. Is this not supported in the free version of fiddler-everywhere?
It's not ideal, but I found a workaround. After the requests have gone off once, I right-click the ones I'm interested in and select "Add new rule". The rule will automatically do an exact match to the URL and sets the action of "Return manually crafted response" If I edit the rule, the header can be added in the raw text.
I have an ASP.Net 4.0 application using Windows Integrated Authentication on IIS7.5 on Windows 2003.
Some users are reporting errors with this message:
Bad Request - Request Too Long
HTTP Error 400. The size of the request headers is too long.
Others succeed in loading pages but have errors loading other resources and performing AJAX calls.
One of the users experiencing intermittent errors has a Kerberos Authorization header of about 5700 characters. This user is a member of 250 AD groups. My theory is that other HTTP headers (inc cookies) may take the total beyond 8000 characters, which if encoded using UTF16, totals over the default 16KB limit.
This page describes using web.config to configure limits on each HTTP header:
http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits/headerlimits
This page describes using registry settings to set limits on HTTP header size and total request size, by default both 16KB:
https://support.microsoft.com/en-us/kb/820129
Do the web.config settings override the HTTP.sys registry settings?
If so, is there a web.config setting for the total request size?
The registry one takes high priority as the driver is the entry point of packets. It is also a server wide setting for all incoming HTTP packets.
The request filtering setting only takes effect when the packets are forwarded to IIS pipeline. It can be set at multiple levels to achieve fine grained control.
There does not seem to be a setting for that.
Have you tried clearing your cookies within your browser?
It could be possible that you have an overly large number of cookies being stored that will be added to any and all requests made within your browser. This can sometimes lead to issues like this. Additionally, you could try running your application within a different browser to see if that affects anything.
I need to create an Akamai 301 redirect rule.
I want to redirect all traffic from:
http://www.example.com/subdirectory/*
To:
http://subdomain.example.com/*
I'm able to do it easily through the control center as a "Relative Redirect Change Hostname only" - but I need the subdirectory stripped out of the target URL. I still need the rest of the path intact.
So example.com/subdirectory/file.html should redirect to subdomain.example.com/file.html.
I can get this to work in htaccess at the web server level, but I need to have it happen at Akamai.
Any suggestions?
You can use "modify outgoing request path" behavior in the configuration and select "remove part of incoming request path" for first occurrence only. This should do the trick.
It's well known that the URL fragment (the part after the #) is not sent to the server.
I do wonder though how fragments work when a server redirect (via HTTP status 302 and Location: header) is involved.
My question is really two-fold:
If the original URL had a fragment (/original.php#foo), and a redirect is made to /new.php, does the fragment part of the original URL simply get lost? Or does it sometimes get applied to the new URL? Will the new URL ever be /new.php#foo in this case?
Regardless of the original URL, if the server redirects to a new URL with a fragment (/new.php#foo), will the fragment get "honored"? Or does the server really have no business interfering with the fragment at all -- and will the browser therefore ignore it by simply going to /new.php??
Update 2022-09-22:
RFC 9110/STD 97 HTTP Semantics (which obsoletes 7231 (and others)), has been published as an INTERNET STANDARD in June 2022. The wording in the newly numbered Section 10.2.2 Location stays the same as before/below.
Update 2014-Jun-27:
RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, has been published as a PROPOSED STANDARD. From the Changelog:
The syntax of the Location header field has been changed to allow all
URI references, including relative references and fragments, along
with some clarifications as to when use of fragments would not be
appropriate. (Section 7.1.2)
The important points from Section 7.1.2. Location:
If the Location value provided in a 3xx (Redirection) response does
not have a fragment component, a user agent MUST process the
redirection as if the value inherits the fragment component of the URI
reference used to generate the request target (i.e., the redirection
inherits the original reference's fragment, if any).
For example, a
GET request generated for the URI reference
"http://www.example.org/~tim" might result in a 303 (See Other)
response containing the header field:
Location: /People.html#tim
which suggests that the user agent redirect to
"http://www.example.org/People.html#tim"
Likewise, a GET request generated for the URI reference
"http://www.example.org/index.html#larry" might result in a 301 (Moved
Permanently) response containing the header field:
Location: http://www.example.net/index.html
which suggests that the user agent redirect to
"http://www.example.net/index.html#larry", preserving the original
fragment identifier.
This should clearly answer your questions.
Update END
this is an open (not specified) issue with the current HTTP specification. it is addressed in 2 issues of the IETF httpbis working group:
#6: Fragments allowed in Location
#43: Fragment combination / precedence during redirects
#6 allows fragments in the Location header. #43 says this:
I just tested this with various browsers.
Firefox and Safari use the fragment in the location header.
Opera uses the fragment from the source URI, when present, otherwise the fragment from the redirect location
IE (8) ignores the fragment in the location URI, thus will use the fragment from the source URI, when present
Proposal:
"Note: the behavior when fragment identifiers from the original URI and the redirect need to be combined is undefined; current User Agents indeed differ on what fragment takes precedence."
[...]
It appears that IE8 does use the fragment idenfitier from Location (the behavior I saw might be limited to localhost).
Thus we seem to have consistent behavior for Safari/IE/Firefox/Chrome (just tested), in that the fragment from the Location header gets used, no matter what the original URI was.
I therefore change my proposal to document that as expected behavior.
this leads to the most browser compatible and future proof (because this issue will eventually get standardized) answer to your question:
A: fragments from original URLs get discarded.
B: fragments from the Location header are honored.
Safari 5 and IE9 and below drop the original URI's fragment if a HTTP/3xx redirect occurs. If the Location header on the response specifies a fragment, it is used.
IE10+, Chrome 11+, Firefox 4+, and Opera will all "reattach" the original URI's fragment after following a 3xx redirection.
Test page: http://www.webdbg.com/test/redir/fragment/.
See further discussion of this issue at http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
Just to let you know, here you can find proper spec. by w3c defining how all should behave: http://www.w3.org/TR/cuap#uri - clause 4.1 - see below:
When a resource (URI1) has moved, an HTTP redirect can indicate its
new location (URI2).
If URI1 has a fragment identifier #frag, then the new target that the
user agent should be trying to reach would be URI2#frag. If URI2
already has a fragment identifier, then #frag must not be appended and
the new target is URI2.
Wrong: Most current user agents do implement HTTP redirects but do not
append the fragment identifier to the new URI, which generally
confuses the user because they end up with the wrong resource.
References:
HTTP redirects are described in section 10.3 of the HTTP/1.1
specification [RFC2616]. The required behavior is described in detail
in "Handling of fragment identifiers in redirected URLs" [RURL]. The
term "Persistent Uniform Resource Locator (PURL)" designates a URL (a
special case of a URI) that points to another one through an HTTP
redirect. For more information, refer to "Persistent Uniform Resource
Locators" [PURL]. Example:
Suppose that a user requests the resource at
http://www.w3.org/TR/WD-ruby/#changes and the server redirects the
user agent to http://www.w3.org/TR/ruby/. Before fetching that latter
URI, the browser should append the fragment identifier #changes to it:
http://www.w3.org/TR/ruby/#changes.
Posting similar issue with the solution faced by me.
Hope it helps to someone with the similar requirement of preserving hash in IE for 302 redirects.
Adding essential parts of the answer instead of links alone
We use SiteMinder authentication in our application.
I figured out that after successful authentication, SiteMinder is doing 302 redirection to user requested application page by using login form hidden variable value (where it stores user requested URL /myapp/ - without hash fragment since it won't be sent to the server) with name similar to redirect. Sample form below
Since redirect hidden variable value contains only /myapp/ without hash fragment and it's a 302 redirect, the hash fragment is automatically removed by IE even before coming to our application and whatever the solutions we are trying in our application code are not working out.
IE is redirecting to /myapp/ only and it is landing on default home page of our app https://ourapp.com/myapp/#/home.
Have wasted almost a day to figure out this behavior.
The solution is:
Have changed the login form hidden variable (redirect) value to hold the hash fragment by
appending window.location.hash along with existing value. Similar to below code
$(function () {
var $redirect = $('input[name="redirect"]');
$redirect.val($redirect.val() + window.location.hash);
});
After this change, the redirect hidden variable is storing user requested URL value as /myapp/#/pending/requests and SiteMinder is redirecting it to /myapp/#/pending/requests in IE.
The above solution is working fine in all the three browsers Chrome, Firefox and IE.
Thanks to #AlexFord for the detailed explanation and providing solution to this issue.