XAR - Attachment [Deleted]

[Xon]

Your addon works OK if Etag is letters and numbers mixed.

So, if I choose default option in ACP for attachment download (Xenforo default mode) and install your addon, etags will be like they should be (mixed numbers and letters)?

The etag should be simple numbers! If it is not, then something is not working correctly.

Try opening this: https://www.endlesshorizon.net/attachments/lwlg5sf-jpg.83/ (accessible to guests)
It keeps on downloading the attachment instead. And my browser names it as download again..

It is this header:

Content-Type: application/octet-stream

Neither my add-on or XenForo should be setting the content type like that if it has a .jpg extension. Additionally, I'm not seeing a filename header which is likely why the content type detection is failing.

Can you try re-uploading the attachment?

 

[BobbyWibowo]

Can you try re-uploading the attachment?

I upload that attachment specifically so that I could link it here. So it was basically a new attachment. I'm not sure what's causing this..

 

[BobbyWibowo]

@Xon, It seems like the cause is your add-on indeed. I used curl -I to check the header (since it's faster), and here're the results when your add-on is enabled and disabled.

Spoiler

Add-on DISABLED (ignore the fact that I removed the session string - I didn't remember that it didn't really matter because curl would crawl the site as a guest):

Add-on ENABLED:

Also, notice how Etag stays the same?

 

[Xon]

@Xon, It seems like the cause is your add-on indeed. I used curl -I to check the header (since it's faster), and here're the results when your add-on is enabled and disabled.

Spoiler

Add-on DISABLED:
View attachment 127591
Add-on ENABLED:
View attachment 127590
Also, notice how Etag stays the same?

I'm baffled. It sets the filename before the Etag, and my own site isn't having an issue with this.

I'll look into this more when I get off work.

 

[rdn]

@BobbyWibowo You use ngx_pagespeed right?
Seems that's causing your problem.

This is my own image header, and it's working as intended right @Xon?

Even if I don't have Etag (add_header Etag $upstream_http_etag) on my Nginx config.

 

[eva2000]

@BobbyWibowo You use ngx_pagespeed right?
Seems that's causing your problem.

yeah @BobbyWibowo you might need to exclude /attachments from ngx_pagespeed optimisation as it won't work without a image file extension anyway. That's why i use bd attachments instead as it gives attachments an extension that ngx_pagespeed can optimise on. With @Xon XAR addon and default XF way of naming attachments, ngx_pagespeed won't optimise them without the image file extension. So just exclude the like in your pagespeed.conf file. If you're using Centmin Mod Nginx server with ngx_pagespeed, see How to exclude specific urls, files, directories from ngx_pagespeed. So in pagespeed.conf add a line for:

pagespeed Disallow "*/attachments/*";

 

[Xon]

This is my own image header, and it's working as intended right @Xon?

Yes, the Etag bit is easy to fix.

yeah @BobbyWibowo you might need to exclude /attachments from ngx_pagespeed optimisation as it won't work without a image file extension anyway. That's why i use bd attachments instead as it gives attachments an extension that ngx_pagespeed can optimise on. With @Xon XAR addon and default XF way of naming attachments, ngx_pagespeed won't optimise them without the image file extension. So just exclude the like in your pagespeed.conf file. If you're using Centmin Mod Nginx server with ngx_pagespeed, see How to exclude specific urls, files, directories from ngx_pagespeed. So in pagespeed.conf add a line for:

pagespeed Disallow "*/attachments/";

Ah, that explains the crazy.

I'll need to test how cloudflare interacts with how XF exports attachments to determine if I I need to add that into my attachments add-on I've been planning on writing.

Planned features:

• Per usergroup node/conversation size limits.
• Per usergroup node/conversation attachment count limits.
• Per usergroup node/conversation dimension limits.
• Per forum attachment types restrictions.
• Global, Extension -> Mime-type list. This will deprecate my SVG Attachment add-on.

This looks to be a fairly simple add-on so I'm hopeful to get it done fairly quickly.

 

[eva2000]

slight correctly forgot the wildcard * on end

pagespeed Disallow "*/attachments/*";

 

[BobbyWibowo]

@eva2000 Yeah, I wanted to mention that you had to add the other asterisk at the end, though I already got it working beforehand. Thanks though!
@Xon I got it working well now, but I had to use proxy_set_header Etag $upstream_http_etag; to get the Etag changed, otherwise it wouldn't change.

 

[Xon]

@Xon I got it working well now, but I had to use proxy_set_header Etag $upstream_http_etag; to get the Etag changed, otherwise it wouldn't change.

Ah, I blame how complex nginx config can be. I'll update my doco to suggest that may be a solution.

 

[rdn]

If I have this config:

location /internal_data {
        location ~ \.(data|html|php)$ {
        add_header Etag $upstream_http_etag;
        add_header X-Frame-Options SAMEORIGIN;
        add_header X-Content-Type-Options nosniff;
        internal;
        }
    internal;
    }

I have this header:
Etag "1342959052"


But if I have this config:

location /internal_data {
        location ~ \.(data|html|php)$ {
        add_header X-Frame-Options SAMEORIGIN;
        add_header X-Content-Type-Options nosniff;
        internal;
        }
    internal;
    }

I have this header:
ETag "5007061c-2f8d"



I think add_header Etag $upstream_http_etag; is not needed?

 

[BobbyWibowo]

Not sure, with or without add_header Etag $upstream_http_etag, the etag would remain the same on my side. Unless changed with the step I mentioned on my latest reply. And I don't really understand the documentation here: http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header

 

[rdn]

the etag would remain the same on my side

alpha numeric or pure integers?

 

[rdn]

add_header Etag $upstream_http_etag;

I don't have this added into my nginx config, and I have this header:

You may want to check this attachment header.

 

[BobbyWibowo]

@RoldanLT Yeah, I just tried commenting out the rule, then tried to upload a new attachment, but for some reason the etag is in alphanumeric.

 

[Xon]

I have this header:
Etag "1342959052"

This is the Etag header that XenForo expects. the alpha numeric one is generated by nginx and isn't what XenForo expects when the etag is checked.

Not sure, with or without add_header Etag $upstream_http_etag, the etag would remain the same on my side. Unless changed with the step I mentioned on my latest reply. And I don't really understand the documentation here: http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header

etag isn't preserved after an X-Accel-Redirect request, but is still available in the $upstream_http_etag variable.

 

[Xon]

FYI, this add-on is no longer supported. The replacement add-on is Attachment Improvements. Be aware that the replacement will have X-Accel-Redirect support disabled by default and requires opt-in.

 

[BobbyWibowo]

Well, this is awkward, it's only been a few days, lol. But oh well, seems like it comes with things that I'll love to have on my board as well, thanks!

 

[rdn]

I will stick with this addon for long time .

 

[BobbyWibowo]

I actually just switched to that add-on, lol