Hi... Thank you for you report, but we'll need a bit more information to help diagnose it. Could you please follow  the instructions on https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details to provide a network log when trying to access this site?

To clarify, when you write "I already contacted the technical support of SBROKER regarding this issue. They told me this site only is supported by chrome/firefox/ie...", do you mean that the site is expected to be supported by Chrome, or that it is not?  Also, what do you mean by "Chrome is working fine on this site!"?

I'm able to reproduce with Chrome 62.0.3198.0, here's a network log.  Chrome tries six times: thrice from 76916 URL_REQUEST, then thrice from 76948 URL_REQUEST.  For each of the six tries, there's a new HTTP2_SESSION, and the request is send on stream 1.  The server responds with:

HTTP2_SESSION_RECV_GOAWAY
                   --> active_streams = 1
                   --> debug_data = "[0 bytes were stripped]"
                   --> error_code = "0 (NO_ERROR)"
                   --> last_accepted_stream_id = 0
                   --> unclaimed_streams = 0

Since error_code = "0 (NO_ERROR)" and last_accepted_stream_id = 0, Chrome retries in accordance with the specification.  However, after a total of six tries with identical results, it gives up.

Seems like a server issue.

Deleted: 761632 chrome-net-export-log.json 290 KB

761632 chrome-net-export-log.json 290 KB View Download

FWIW, I couldn't reproduce it myself (beta channel on Linux), so there may be slightly more to it than that.

Hey, sorry for my enunciation, I am no native english speaker :p

I meant with "I already contacted the technical support of SBROKER regarding this issue. They told me this site only is supported by chrome/firefox/ie..." that the support told me, that they design the webpage, to be supported by the "big browsers" IE,Chrome,Firefox,Safari. I tested this webpage with Google Chrome (Version 60.0.3112.113 (64-bit))and it works like a charm, without any issue.

Even on Microsoft Edge the webpage is working fine.

But with my Chromium version I get this error message.

Hope it is clear now

Hmm, trying on my phone, which has more versions, not reproducible in stable or beta, is reproducible in canary. 

Sorry I am no developer, what means canary in this context? Is it a kind of build between stable and beta? :D

No, even riskier than beta; it's roughly a daily build off the main development branch.  The version you originally reported it with (62.0.3202.0) corresponds to a canary as well (though sounds like you may have built it yourself?).

The summary is that it seems likely something changed in what we do in 62 vs. 61 that made that server unhappy. 

Okay, then I'll try bisecting.  Thanks.

I don't even know how I could build it myself :D
This is very interesting. It all started with this issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=628312&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

Since google chrome still has this white line, I started to get to know how I can use Chromium. And somehow I did manage it and try to help to improve it. =)

Re comment #4: thank you for the clarification.  Yes, it makes perfect sense now.

Re comment #9: you can try using Google Chrome Beta, or the even more recent Google Chrome Dev, or the most-most recent Google Chrome Canary, instead of using Google Chrome Stable.  Then you'll get bugfixes earlier, but there might be more broken things.  This way you do not have to compile Chromium for yourself, and you'll get automatic updates.

Bisect output:
You are probably looking for a change made after 489123 (known good), but no later than 489132 (first known bad).  CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/ddd3b95b86917f5c0e61563689762219bad18d87..ffd895fc68d672eea839263d051775226fac20bf

The website started to fail in Chrome since https://crrev.com/c/571292.  This is a spec-compliant change, the bug is in the server or in a middle box (possibly a load balancer or reverse proxy that the site operator uses).

I can reproduce the issue with a locally compiled tip-of-the-tree Chrome.  If Chrome sends an initial HTTP/2 SETTINGS frame without a SETTINGS_MAX_HEADER_LIST_SIZE entry, or with a SETTINGS_MAX_HEADER_LIST_SIZE value of 16*1024 or 32*1024, then the request succeeds.  If, however, the value of SETTINGS_MAX_HEADER_LIST_SIZE is 32*1024+1, 33*1024, 64*1024, 256*1024 (Chrome default), or 1024*1024, then the request fails.  This is very similar to  issue 751642 , where the problem was reportedly caused by the load balancer, and was solved after firmware upgrade.

This is not a Chrome issue, it's working as intended, I'm closing it as a duplicate of  issue 751642 .