Planned Downtime @ 2018-04-21 00:00:00 GMT.

[EEVblog]

I don't know that it's a "problem" as such - just a size limitation.

The new server does have more drive space than before IIRC, but it's not cloudy infinite.
So I don't expect we could raise the limits much.

[EEVblog]

New server bandwidth

[IanB]

Just testing that MathJax is still available:

$$ ax^2+bx+c=0 $$

Yes, cool 

[nctnico]

Are the PDF attachements also fixed?

First I have heard of it... whats the problem?

PDF attachements never open in Acrobat. Every other website works but not EEVblog. AFAIK this is a well known problem for EEVblog users so most refrain from attaching PDFs.

For example the PDFs attached to this message:
https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/msg1371771/#msg1371771
Firefox (the latest version) says the file type is unkown and wants to open it with a text editor.

[tautech]

Are the PDF attachements also fixed?

First I have heard of it... whats the problem?

PDF attachements never open in Acrobat. Every other website works but not EEVblog. AFAIK this is a well known problem for EEVblog users so most refrain from attaching PDFs.

For example the PDFs attached to this message:
https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/msg1371771/#msg1371771
Firefox (the latest version) says the file type is unkown and wants to open it with a text editor.

OK just checked on this thread ^.
File downloads fine and it opens in a tab in your browser fine too. In Chrome with a right click on the downloaded pdf you can set "Always open in Acrobat" and when set it does just that.

[nctnico]

I guess Chrome is doing something non-standard then and tries to guess based on the extension. According to the specs the webserver is supposed to let the browser know what kind of file (mime-type in the HTTP header) it is receiving regardless of the extension. If that is broken a browser gets a binary blob with unknown content. BTW the same goes wrong when people attach pictures. Firefox can't deal with those either probably due to the missing mime-type. As I wrote before: EEVblog is the only website I visit where this doesn't work properly.

[gnif]

Chrome works fine for me too, I get a prompt to download the file.

SMF is actually serving the file, not Nginx directly.

Code: [Select]

wget "https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/?action=dlattach;attach=397073" -O/dev/null --debug
DEBUG output created by Wget 1.19.4 on linux-gnu.

Reading HSTS entries from /home/geoff/.wget-hsts
URI encoding = ‘UTF-8’
--2018-04-21 07:44:02--  https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/?action=dlattach;attach=397073
Resolving [url=http://www.eevblog.com]www.eevblog.com[/url] ([url=http://www.eevblog.com]www.eevblog.com[/url])... 104.31.75.133, 104.31.74.133, 2400:cb00:2048:1::681f:4b85, ...
Caching [url=http://www.eevblog.com]www.eevblog.com[/url] => 104.31.75.133 104.31.74.133 2400:cb00:2048:1::681f:4b85 2400:cb00:2048:1::681f:4a85
Connecting to [url=http://www.eevblog.com]www.eevblog.com[/url] ([url=http://www.eevblog.com]www.eevblog.com[/url])|104.31.75.133|:80... connected.
Created socket 4.
Releasing 0x0000555c8cee0910 (new refcount 1).

---request begin---
GET /forum/testgear/siglent-sds1104x-e-in-depth-review/?action=dlattach;attach=397073 HTTP/1.1
User-Agent: Wget/1.19.4 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: [url=http://www.eevblog.com]www.eevblog.com[/url]
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Fri, 20 Apr 2018 21:44:03 GMT
Content-Type: application/octet-stream
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d9d87d66c77bd7b75de4ed75d84068bec1524260642; expires=Sat, 20-Apr-19 21:44:02 GMT; path=/; domain=.eevblog.com; HttpOnly
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Set-Cookie: PHPSESSID=hpi2vnv19st40mu1c569nlhi77; path=/
Pragma:
Content-Transfer-Encoding: binary
Expires: Sat, 20 Apr 2019 21:44:03 GMT
Last-Modified: Wed, 21 Feb 2018 16:27:38 GMT
ETag: W/"397073SDS1104X-E Review 1-25.pdf1519230458"
Content-Disposition: attachment; filename="SDS1104X-E Review 1-25.pdf"
Cache-Control: max-age=31536000, private
Vary: Accept-Encoding
X-Backend: web2.eevblog.com
Server: cloudflare
CF-RAY: 40eaca36203b19bc-SYD

---response end---
200 OK
cdm: 1

Stored cookie eevblog.com -1 (ANY) / <permanent> <insecure> [expiry 2019-04-21 07:44:02] __cfduid d9d87d66c77bd7b75de4ed75d84068bec1524260642

Stored cookie [url=http://www.eevblog.com]www.eevblog.com[/url] -1 (ANY) / <session> <insecure> [expiry none] PHPSESSID hpi2vnv19st40mu1c569nlhi77
Registered socket 4 for persistent reuse.
Length: unspecified [application/octet-stream]
Saving to: ‘/dev/null’
Failed to set xattr ‘user.xdg.origin.url’.

/dev/null                                                                           [    <=>                                                                                                                                                                                              ] 756.99K   840KB/s    in 0.9s   

2018-04-21 07:44:04 (840 KB/s) - ‘/dev/null’ saved [775161]

Content-Disposition: attachment; filename="SDS1104X-E Review 1-25.pdf"

Content-type is not a required header according to the specs, if your browser is misbehaving either it's a bug or you have a plugin installed that is messing things up:

https://tools.ietf.org/html/rfc7231#section-3.1.1.5

   A sender that generates a message containing a payload body SHOULD
   generate a Content-Type header field in that message unless the
   intended media type of the enclosed representation is unknown to the
   sender.  If a Content-Type header field is not present, the recipient
   MAY either assume a media type of "application/octet-stream"
   ([RFC2046], Section 4.5.1) or examine the data to determine its type.

[nctnico]

I have plain & simple Firefox (the most recent version but previous versions had the same problem) with ABP as the only extension and no tweaking of anything. Firefox says it can't determine the type of the file. And I think you are mis-interpreting the specs. It says the sender (server) should indicate the content type unless it really really really can't do it. It also says that the recipient (browser) may choose what to do when the content type is unknown: treat it as a blob or try to guess. So if you want the transfer of files to always work over HTTP then there is no other option than having the webserver supply the correct content type.

[gnif]

I have plain & simple Firefox (the most recent version but previous versions had the same problem) with ABP as the only extension and no tweaking of anything. Firefox says it can't determine the type of the file. And I think you are mis-interpreting the specs. It says the sender (server) should indicate the content type unless it really really really can't do it. It also says that the recipient (browser) may choose what to do when the content type is unknown: treat it as a blob or try to guess. So if you want the transfer of files to always work over HTTP then there is no other option than having the webserver supply the correct content type.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

I am not saying that this should not be fixed, I am however saying that it is not a critical problem nor high priority.

File type is not detected using the extension under Linux, it is a bad practice to do so on any operating system. The mime type is detected by scanning the file headers for known signatures, this imposes additional server load. Assuming a file is what it is based on extension is a dangerous practice and can lead to downloading a "PDF" that is really a malicious file, simply because the file extension was trusted.

[IanB]

So if you want the transfer of files to always work over HTTP then there is no other option than having the webserver supply the correct content type.

But the web server doesn't know the correct content type. The file was uploaded by the user as an attachment to a post, and the only information provided by the user was the file name and extension. When you view the post, you get back the information originally provided; no more, no less.

The only way the server could indicate that the attachment is a PDF file is to look inside the file and interpret the contents, or to look at the extension and associate .pdf with a PDF file. Both of which the browser can do just as well.

In this case the server has no business deducing or guessing, it should just hand back the data as it received it with the same file name. So I think the server is behaving as it should.

[nctnico]

So if you want the transfer of files to always work over HTTP then there is no other option than having the webserver supply the correct content type.

But the web server doesn't know the correct content type. The file was uploaded by the user as an attachment to a post, and the only information provided by the user was the file name and extension. When you view the post, you get back the information originally provided; no more, no less.

The only way the server could indicate that the attachment is a PDF file is to look inside the file and interpret the contents, or to look at the extension and associate .pdf with a PDF file. Both of which the browser can do just as well.

In this case the server has no business deducing or guessing, it should just hand back the data as it received it with the same file name. So I think the server is behaving as it should.

The makers of Firefox (not exactly a niche browser) seem to have a different opinion so don't shoot the messenger. Life sucks and sometimes you have to fix things which are not really your problem to start with.

[gnif]

So if you want the transfer of files to always work over HTTP then there is no other option than having the webserver supply the correct content type.

But the web server doesn't know the correct content type. The file was uploaded by the user as an attachment to a post, and the only information provided by the user was the file name and extension. When you view the post, you get back the information originally provided; no more, no less.

The only way the server could indicate that the attachment is a PDF file is to look inside the file and interpret the contents, or to look at the extension and associate .pdf with a PDF file. Both of which the browser can do just as well.

In this case the server has no business deducing or guessing, it should just hand back the data as it received it with the same file name. So I think the server is behaving as it should.

The makers of Firefox (not exactly a niche browser) seem to have a different opinion so don't shoot the messenger. Life sucks and sometimes you have to fix things which are not really your problem to start with.

If you really want this fixed, contact the SMF developers, this is not a bug with our forum or the servers.

[Cerebus]

I think someone's missed the point. The writers of SMF obviously took the decision that, when an end-user uploads content, they would not make any assumptions about what the MIME type of that content was. To take an uploaded file and assume the MIME type could completely misrepresent the content type. Relying on the fact that someone puts 'pdf' or 'jpg' on the end of a file could allow all sorts of malfeasance - see below (a benign example):

[nctnico]

IMHO the application receiving the file should do the check AFTER it has been scanned automatically by the virus scanner. There really isn't any need to be more secure than necessary because that just causes extra nuisance with zero added security.

[xrunner]

I have to say that the forum is really responding faster now. Really good work! 

[ez24]

I will be moving the forums and website over to the new cluster at 2018-04-21 00:00:00 GMT.
Unfortunately due to the huge jump software versions this can not be done without causing some downtime.

Thank you for your hard work helping us 

[aqarwaen]

can some say me why i get database error,if try acces from wifi?mobile data works fine without.i get error on my tablet,smarttv,phone and pc also

[gnif]

can some say me why i get database error,if try acces from wifi?mobile data works fine without.i get error on my tablet,smarttv,phone and pc also

Likely an overlooked setting to be updated, I will try to reproduce and correct it. Thanks for reporting it.

Edit: I can not reproduce it, it sounds like you have it cached somewhere, perhaps your ISP has cached the error from during the update.

[Cerebus]

Is there an issue with the 'ignore topic' feature? I haven't changed my forum settings but the ignore topic button seems to be gone from my updated topics page.

[tautech]

Is there an issue with the 'ignore topic' feature? I haven't changed my forum settings but the ignore topic button seems to be gone from my updated topics page.

Interesting, mine's unchanged too like Wilfred's.

I retain mine after the upgrade. But I also never got the ability to move topics that was introduced before the move. So my experience may not be the most reliable guide.

There are a couple of ways to have Move Topics visible and everyone has it by default at the bottom left in the first page of a topic they have started. In 'normal' forum view it's just above 'Quick Reply'.

[BU508A]

can some say me why i get database error,if try acces from wifi?mobile data works fine without.i get error on my tablet,smarttv,phone and pc also

Likely an overlooked setting to be updated, I will try to reproduce and correct it. Thanks for reporting it.

Edit: I can not reproduce it, it sounds like you have it cached somewhere, perhaps your ISP has cached the error from during the update.

No, it is not a cache issue imho. I have the same behaviour here: Linux/Windows + Firefox works perfectly well but with my iPad 4 and Safari I get this "Database error". It needs reloadings from 1 up to 20 or 30 attempts until I get what I'm looking for. It seems also, that it is some kind of load dependend. I thought first, it could be a cache thing (DNS, browser etc.), therefore I was waiting for the TTL to become obsolete. But it seems, it is still coming up with this database error.

[hwj-d]

can some say me why i get database error,if try acces from wifi?mobile data works fine without.i get error on my tablet,smarttv,phone and pc also

Likely an overlooked setting to be updated, I will try to reproduce and correct it. Thanks for reporting it.

Edit: I can not reproduce it, it sounds like you have it cached somewhere, perhaps your ISP has cached the error from during the update.

No, it is not a cache issue imho. I have the same behaviour here: Linux/Windows + Firefox works perfectly well but with my iPad 4 and Safari I get this "Database error". It needs reloadings from 1 up to 20 or 30 attempts until I get what I'm looking for. It seems also, that it is some kind of load dependend. I thought first, it could be a cache thing (DNS, browser etc.), therefore I was waiting for the TTL to become obsolete. But it seems, it is still coming up with this database error.

Me too!! Meanwhile it is online possible to login from my S7! IPad, Linux, Win10, different browsers have all passed one after another with this database error!
And I think, this is the last time, i'm able to login now....
€: Cache, cookies cleaned already

[hwj-d]

Ok, i'm in with my desktop again. But it tooks more than ten attempts in a row.
Maybe a server overload, storage misconfiguration?

[gnif]

Ok, I will have another dig though, it does seem very odd that it intermittent as everything is in sync.

Certainly not overloaded, perhaps there is a plugin still trying to use the old database configuration.

[Cerebus]

I saw the database error a few times shortly after the server move, but, unlike others, I haven't seen it for a few days,

On the subject of 'ignore topics': I turned it off, and turned it on again in my profile and the option reappeared. So if anybody has the same problem "turn it off and on again".