Forum Activity for @soaringeagle

mailgun stopped working

Design and Skin Customization

i dont know wheres best place to put these sort of posts
maybe we need a bug report general tech support section

but mailgun seems set up right but cant send mail with mailgun set as the default mail handler
updated by @soaringeagle: 01/28/16 04:27:07PM

sitemap crawls neverending weird url generation

Ning To Jamroom

id imagine since the loop seems never ending its coming from evry page in those 2 discussions
but also suspect it might be a curruption in the files in jr cache

update on large file upload issues

Ning To Jamroom

man i wanna curse and scream now
for 6 months cloudflare had lied to me
i demanded a full refund from the second i upgraded to pro

update on large file upload issues

Ning To Jamroom

its fixed! 1 of the settings fixed it after rebooting server (restarting services didnt do it0)
but have to run 2-3 more tests to rule out some caching options

update on large file upload issues

Ning To Jamroom

nothing server side has fixed it
when your able and have time i might need you to take a closer look at it
updated by @soaringeagle: 09/27/15 07:34:34AM

update on large file upload issues

Ning To Jamroom

seems most likely to be an issue with SSLRenegBufferSize
this has been a nightmare to figure out
this setting you might want to add to the htaccess increzasing it by default
i wont be sure its fixed till tomorow morning
but i think this is the issue since i tried every other ossible fix i can find

update on large file upload issues

Ning To Jamroom

ok i have tried every fix there is on every forum

now heres what i just uncovered
413 Payload Too Large (RFC 7231)
The request is larger than the server is willing or able to process. Called "Request Entity Too Large " previously.

and
6.5.11. 413 Payload Too Large

The 413 (Payload Too Large) status code indicates that the server is
refusing to process a request because the request payload is larger
than the server is willing or able to process. The server MAY close
the connection to prevent the client from continuing the request.

If the condition is temporary, the server SHOULD generate a
Retry-After header field to indicate that it is temporary and after
what time the client MAY try again.


most recent attempts to fix it involved setting
LimitRequestBody
set to unlimited
SSLRenegBufferSize
set very high

upgraded php too
dded some odbc settings in my.cnf to limit cpu overuse
ive got it tuned to handled much more requests per second but cant solvde this large file upload limit
i have all cachings on all pages with create in the ur disabled
(varnish and coudflare)
i just dont know what else to try

sitemap crawls neverending weird url generation

Ning To Jamroom

i checked every template
i wonder if its currupted in cache or something

sitemap crawls neverending weird url generation

Ning To Jamroom

its absolutely nowhere in any templates
i believe it must be either from an early build of the ning importer, or when all the images were wiped out theres some currupted link looping going on
cause its only in 2 picture heavy discussions nowhere else
but i checked every possible template thouroughly

i do have insite that might find the weird links but it takes forever to run (never even got 10% of the site checked) and even with only 10% of the site checked generating the reports took i think over a day and was like 4-6 gigs
if i shut off everything but link checking the reports are still huge

sitemap crawls neverending weird url generation

Ning To Jamroom

CONFUSED why would there be such a code and where
i mean arent those urls built dynamicly with smarty codes and therefore it should affect all forum urls? like