New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error 404 search with IE 11 #2768

Closed
Alexwii opened this Issue Sep 2, 2016 · 17 comments

Comments

Projects
None yet
5 participants
@Alexwii

Alexwii commented Sep 2, 2016

Expected Behavior

When we search someone with IE 11, we have a 404 error. Before 2.1, we had not this problem.
image

Current Behavior

Steps to Reproduce (for bugs)

  1. Search someone
  2. Click on search
  3. Error 404

Context

We use IE 11 on production... We know it's not the better browser but it's the most easier update in production.

Your Environment

  • Graylog Version: 2.1
  • Elasticsearch Version: 2.3
  • MongoDB Version: 3.2.7
  • Operating System: RHEL 6.6
  • Browser version: IE 11
@joschi

This comment has been minimized.

Contributor

joschi commented Sep 2, 2016

@Alexwii Which URL does your browser try to open?

Please post some details about your Graylog setup.

@Alexwii

This comment has been minimized.

Alexwii commented Sep 2, 2016

any search, exemple :
http://servername.company.com/search?rangetype=relative&fields=message%2Csource&width=1219&highlightMessage=&relative=300&q=source%3Asox007

What's detail you want ?

And I add when we click on next the same error appear.

@joschi

This comment has been minimized.

Contributor

joschi commented Sep 2, 2016

@Alexwii Is http://servername.company.com/ the correct address for your Graylog server?

What's detail you want ?

The complete Graylog configuration file (excluding sensitive information like password_secret and root_password_sha2), how you've installed Graylog, if you're using a reverse proxy, and some information about your network setup.

@Alexwii

This comment has been minimized.

Alexwii commented Sep 2, 2016

Yes, it's the correct address, I just changed the name for confidentiality.

Yes, but all is ok when I use Chrome.

Configuration files:
http://pastebin.com/ke8gP6em

@edmundoa

This comment has been minimized.

Member

edmundoa commented Sep 2, 2016

Hi @Alexwii,

I just tried to repeat the steps you provided to reproduce the issue in IE 11 but it works fine for me.

Looking at your config file, I'm seeing something odd: Your web interface should be available under http://adressipcorrect:9000/, but on the link you posted before the port number is gone http://servername.company.com/search. Was that a mistake while replacing the server name or is there some proxy in between your browser and Graylog? If there is a proxy, you should check the settings or share them to see if we can catch any mistakes there.

Thank you.

@Alexwii

This comment has been minimized.

Alexwii commented Sep 2, 2016

Hello @edmundoa

We have add an iptables rules who send all connection on port 80 to port 9000.

The problem is not resolved if we use http://servername.company.com:9000/search

@edmundoa

This comment has been minimized.

Member

edmundoa commented Sep 2, 2016

Now that I think of it, the 404 you are getting is not even coming from Graylog: both the Graylog web interface and the server have custom 404 pages.

By the way, you said the problem occurs when "click on search", what does exactly mean? Also, what is the URL your browser had in the navigation bar at that point?

@Alexwii

This comment has been minimized.

Alexwii commented Sep 2, 2016

So... I will describe in better than I can.

  1. I open IE11 and I go to Graylog. I connect with my username.
  2. When I am connected, I am on http://servername.company.com/search
  3. When I want launch a search, I click on the magnifying glass:
    image

3.bis Or if I want go to the next page:

image
4. After click, I have the error "HTTP 404 Not Found"

Maybe the cause it's my configuration. But we don't use proxy... I don't know, I continu to search...

@edmundoa

This comment has been minimized.

Member

edmundoa commented Sep 2, 2016

Thank you for clarifying that.

To be honest I don't know where the issue is, but it is odd that http://servername.company.com/search loads in your browser, but http://servername.company.com/search?rangetype=relative&fields=message%2Csource&width=1219&highlightMessage=&relative=300&q=source%3Asox007 does not. I tried to load that exact URL (replacing the hostname) in my test IE 11, and the page loaded without a problem.

Can you share the iptables rules you use to redirect the traffic to port 9000? Also, is there something else running in that server that may be getting that request?

@henrikjohansen

This comment has been minimized.

henrikjohansen commented Sep 2, 2016

@edmundoa We have some users that report the exact same issue ... they get a 404 when clicking on links (pagination, stream name, etc) using IE11. Using Chrome or FF resolves those 404's.

@tommy13v

This comment has been minimized.

tommy13v commented Sep 2, 2016

Hope it's not too simplistic but could it be related to the browser's cache?

@Alexwii

This comment has been minimized.

Alexwii commented Sep 5, 2016

Can you share the iptables rules you use to redirect the traffic to port 9000? Also, is there something else running in that server that may be getting that request?

@edmundoa
I don't think it's a problem with Iptables, because all works with Chrome and before with 2.0.3 all was fine. But ok:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 redir ports 9000
REDIRECT   udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:80 redir ports 9000

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

And nop, we have just Graylog who use port 80/9000.

Hope it's not too simplistic but could it be related to the browser's cache?

@tommy13v
Already does, and don't correct the problem...

@edmundoa

This comment has been minimized.

Member

edmundoa commented Sep 5, 2016

I was able to reproduce this issue by forcing IE 11 to render Graylog in "Compatibility view". @Alexwii, @henrikjohansen could you please try disabling IE's compatibility view for Graylog and see if that helps with the issue? You may need to uncheck the "Display intranet sites in compatibility view" checkbox, depending on your network setups.

@Alexwii

This comment has been minimized.

Alexwii commented Sep 5, 2016

Your tip works, all is ok. But I don't know why we had not this problem before... !

@edmundoa

This comment has been minimized.

Member

edmundoa commented Sep 5, 2016

So far I have seen two issues here:

  • Even when setting the X-UA-Compatible header and meta tags for IE to use the latest standards mode (as we did in 2.0, and still do), the page behaves a bit different when clicking around if it is in the compatibility view list
  • We changed how we serve the web interface html in the server, and now we only serve the html asset from the URI set in web_listen_uri in your Graylog configuration

When the site is in IE's compatibility view list, clicking through the page triggers some extra requests to the Graylog API, that were returning the web interface html asset in 2.0, but now they return a 404. These requests don't happen when the site is not in the compatibility view list, or when using any other browser.

@Alexwii

This comment has been minimized.

Alexwii commented Sep 5, 2016

And you think the problem will be corrected in your future update ?

@edmundoa

This comment has been minimized.

Member

edmundoa commented Sep 5, 2016

Investigating a bit more into the issue, I saw that part of what I said before is not right. We are still delivering the web interface HTML document, but checking the Accept header most browsers set to text/html. IE 11 running in compatibility mode does not set that header, and therefore doesn't get the HTML, but a 404 page.

I guess we can fix it by relaxing the condition where we deliver the HTML document. I'll keep on looking into it.

@edmundoa edmundoa added the bug label Sep 5, 2016

@edmundoa edmundoa self-assigned this Sep 5, 2016

@edmundoa edmundoa added this to the 2.1.1 milestone Sep 5, 2016

edmundoa added a commit that referenced this issue Sep 6, 2016

Fix 404s on IE 11 using compatibility view
When Graylog is running on an intranet, IE 11 may be requesting the site
in compatibility view, depending on the organization and user settings.
That applies even when properly setting the X-UA-Compatible header and
meta tags.

Making requests in compatibility view, IE does not include either
`text/html` or `application/xhtml+xml` MIME types in the `Accept`
header, which are the values we checked in order to deliver the web
interface HTML document when requesting a resource that doesn't exist
(i.e. when clicking on a page number on the search page).

Unfortunately, the way legacy IEs work is also odd in the way it
includes `Accept` headers on requests, being `*/*` the only one that is always
included. You can read more about it here:
https://blogs.msdn.microsoft.com/ieinternals/2009/07/01/ie-and-the-accept-header/

To solve this issue, these changes relax the media types comparison on
`WebAppNotFoundResponseFilter`, by also serving the web interface HTML
document if any of the request headers is compatible with `text/html` or
`application/xhtml+xml`. In that way we also consider that requests with
a wildcard MIME type will be able to handle the HTML document, but we
still avoid serving HTML if the request specified another accepted MIME
type.

Fixes #2768

edmundoa added a commit that referenced this issue Sep 6, 2016

Fix 404s on IE 11 using compatibility view
When Graylog is running on an intranet, IE 11 may be requesting the site
in compatibility view, depending on the organization and user settings.
That applies even when properly setting the X-UA-Compatible header and
meta tags.

Making requests in compatibility view, IE does not include either
`text/html` or `application/xhtml+xml` MIME types in the `Accept`
header, which are the values we checked in order to deliver the web
interface HTML document when requesting a resource that doesn't exist
(i.e. when clicking on a page number on the search page).

Unfortunately, the way legacy IEs work is also odd in the way it
includes `Accept` headers on requests, being `*/*` the only one that is always
included. You can read more about it here:
https://blogs.msdn.microsoft.com/ieinternals/2009/07/01/ie-and-the-accept-header/

To solve this issue, these changes relax the media types comparison on
`WebAppNotFoundResponseFilter`, by also serving the web interface HTML
document if any of the request headers is compatible with `text/html` or
`application/xhtml+xml`. In that way we also consider that requests with
a wildcard MIME type will be able to handle the HTML document, but we
still avoid serving HTML if the request specified another accepted MIME
type.

Fixes #2768

dennisoelkers added a commit that referenced this issue Sep 7, 2016

Fix 404s on IE 11 using compatibility view (#2782)
When Graylog is running on an intranet, IE 11 may be requesting the site
in compatibility view, depending on the organization and user settings.
That applies even when properly setting the X-UA-Compatible header and
meta tags.

Making requests in compatibility view, IE does not include either
`text/html` or `application/xhtml+xml` MIME types in the `Accept`
header, which are the values we checked in order to deliver the web
interface HTML document when requesting a resource that doesn't exist
(i.e. when clicking on a page number on the search page).

Unfortunately, the way legacy IEs work is also odd in the way it
includes `Accept` headers on requests, being `*/*` the only one that is always
included. You can read more about it here:
https://blogs.msdn.microsoft.com/ieinternals/2009/07/01/ie-and-the-accept-header/

To solve this issue, these changes relax the media types comparison on
`WebAppNotFoundResponseFilter`, by also serving the web interface HTML
document if any of the request headers is compatible with `text/html` or
`application/xhtml+xml`. In that way we also consider that requests with
a wildcard MIME type will be able to handle the HTML document, but we
still avoid serving HTML if the request specified another accepted MIME
type.

Fixes #2768
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment