requinix

The Content-Length in the request header (if there even is one) does not describe the file. It describes the entire request. Take a look at how multipart/form-data requests are structured and that might help explain what's going on. https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST Could very well be. But these things are also frequently dependent upon the application itself. Maybe what you need is not so much a library but a curated database you can read. Assuming you validated that the provided type was correct, because if not then you shouldn't be storing it at all, then you would use it instead of whatever type you tried to guess it was. Sure. Why would it matter if they were different?

It can't be: the size is not just the size of the file but the amount of content that the browser sent to the server. If this did not match what the request actually had then there would have been problems. That's the big one. MIME type detection is naive and optimistic: it assumes that if the file has a few bytes in a certain location then the entire file is that one type. It won't be able to detect files with mixed content (think PHP code buried in the middle of some HTML) or files using containers (OpenDocument files are ZIP archives) or many types of text file formats. It can accurately detect audio and video data as well as "unique" binary formats. That's where you have to enter with some specific knowledge to make decisions. The detected types are correct, they're just not what you expected or wanted. Windows particularly tends to identify files by extension, then equate those extensions with MIME types according to whatever software is installed. For example, having Office/Excel will tell the system that .csv files are vnd-ms.excel because... well, because that's what it's been doing for a very long time, but point is that a Windows browser will happily report vnd.ms-excel because that's what it knows the file as. That's especially useful for text files. Linux too will frequently deem a file a certain type according to the extension and only use MIME detection as a fallback. And I agree with that. It's a huge pain to try to deduce MIME type or the correct file extension just from the contents. So don't do that. Instead, in the general case, validate that the MIME type you detect is consistent with the extension - and optionally with the reported MIME type. (That's the general case. For more specific cases, like you only want to support images, sometimes it can be done reliably with only MIME types.) And above all else, if you want to store arbitrary files, install a virus scanner or two. Mostly disagree. While you should assume the client is malicious, in the real world that's very often not the case, and throwing away data because it might be incorrect is hurting youself. But how do you know it does not match? It's easy to pick examples like images, but what about HTML with some PHP code buried in the middle? You'll receive a .php extension but detection will say it's .htm/html.

If you want advice about how to design this application then we're going to need a LOT more detail than what you've given so far. Especially about how users "own" APIs.

Process them in batches through cronjobs?

If you're looking for "tips" and "tricks" then what you mean is you want shortcuts so that you don't have to understand how stuff works. If you don't like thinking about it then don't think about it: do exactly what guides and blogs and documentation say to do and don't stray from their advice.

The "Apache" in "Apache log4j" means the umbrella project, not the web server.

Given that $types has only one entry in it, yes: using key() and current() is a good solution in practice. It wouldn't work if something was iterating over $types using next(), but that is very likely not happening.

Is authentication supposed by handled by a client certificate or by a standard username and password? That error message suggests the connection is fine and the credentials are wrong - after all, the client must be able to connect to the server if it's able to report to you information like "the credentials are wrong".

There's a syntax error in your query. Take a look to see if you can spot it, otherwise use mysqli::$error to see what the error message can tell you.

If the arrays are crafted in a very specific way, ie. with the fields set in the order that they should be sorted on. A custom sort is a little (still a one-liner) more complicated but won't suddenly break if the arrays are built differently.

...no? Or did you change how the form works? Because everything so far has been with POST.

Use usort.

Stop throwing code at it with the hope that everything will start working and instead spend a minute thinking about what it is you're doing. It's a far more efficient method for solving problems. You've decided that $_POST has the page number of the results you want, and you put that value into $page. If you want to change page numbers then you need to include in the form data a new value for "page". The two buttons for previous and next are the things that the user will interact with, and they can each contain whatever new value it takes to make their actions happen. The previous button should use the previous page number and the next button should use the next page number - that would be $page-1 and $page+1 respectively, right? So you need to put the $page-1 and $page+1 numbers into the two buttons' values. We can worry about accidentally browsing to page 0 after that.

#i dont know how to increment and decrement inside the value echo "<button type='submit' name= 'page' value = '' class='btn btn-primary'>PREV</button>"; echo "<button type='submit' name= 'page' value = '' class='btn btn-primary'>NEXT</button>"; You might be overthinking this. It's true that you can't change the $page variable inside the string, which isn't exactly what you should be doing anyways, but you can do things outside the string. See what you can come up with along those lines. Also don't forget that you still need the two if checks you had before for when the $page is >1 or <the page count.

By policy we don't delete accounts, except to comply with laws like GDPR. If you don't want to use your account then you can simply not use your account.

Sorry but it is documented. Like strtotime, it will assume the input is a valid date/time string and try its best to make the most of it, and there are a bunch of different things that are supported. https://www.php.net/manual/en/datetime.formats.php

If you have further questions, please reply in this thread instead of reaching out over private message. <?php if (isset($_GET['page']) { $page = $_GET['page']; } else { $page = 1; } ?> $_GET is only used for values that go into the URL. They're easy to spot. Your form is using the POST method (which I would say is correct) so all values send that way must be accessed through $_POST. Try fixing that. If it's still not working then post (not link, please) the full code you have now with a detailed description of what you expected it to do and what it's actually doing instead.

The concept is called "pagination". For most people that has to do with database queries, but with your API calls it's still very similar in execution. You need to get the desired page number from the form; if you want Prev and Next buttons then you could include the page number in the form and know which button means -1 or +1, but easier would be to make the buttons have the actual page number as their values. Processing the form to get the page number has to happen before you use the API, of course. Your $page > 1 and $page < $result->pages checks are good for deciding whether to show the Prev and Next buttons, but since you need the page number before you use the API, you can't use the results of that API call to decide what to do. My suggestion is: 1. Get the $page from the form data (if it is >=1) or use 1 if there wasn't a valid number given 2. Call the API with the page number 3. Show the results like normal 4. In the form, if $page > 1 then show the Prev button, and if $page < number of pages then show the Next button 5. For the two buttons, give them a name of "page" and a value of $page - 1/$page + 1 appropriately: when someone clicks either button then that will submit a "page" in the form data for your code to use

Or it could be Apache couldn't log anything useful there because the client did not send a request in a timely manner - which is exactly what 408 means. Ignore that line, possibly by a regex or something, or ignore the warning from AWStats itself.

For what purpose?

Have you checked your server error logs yet?

You'll need a local environment for testing that is identical to the live environment. If it's running on "Linux", which is far more capable than you seem to think it is, then that's what you should have too. Learn the codebase inside and out, then check the PHP migration guides for 5.3 -> 5.4 -> 5.5 -> 5.6 -> 7.0 -> 7.1 -> 7.2 -> 7.3 -> 8.0, since that's where you're starting and where you're going. There have been a lot of changes over the few years and you're lagging behind by a lot. Decide what is obviously relevant and address it now. Make sure that your PHP reports everything wrong. E_ALL is not everything but the things you should commonly care about. Set error_reporting to -1 and make sure nothing reverts that, then double-check you have errors being logged as they need to be. Deploy the application locally and see what happens. However long it took you to get to this point, take at least that much more time with testing.

Two words: browser detection. As in using IE's conditional tags.

The setAccessible method. Not really. I'm a proponent of simple when it makes sense, but simple shouldn't be the goal.

Yes, it's possible, but you're getting to the point where you're abusing reflection so don't. If making properties public is not acceptable then use methods. The problem isn't the attributes - it's the properties. PHP doesn't have visibility on property reads/writes, so unless you want to switch to an immutable design with readonly properties... Here's the thought process: 1. Properties are nice, but you need the values from them. Don't want to make them public, shouldn't use reflection (IMO) to bypass visibility. 2. So you can't get the data from the properties. What other mechanisms are available? 3. Get the data from the methods. Dumb little getter methods with no logic. 4. How to get the "ranked list" data? At this point your answer is attributes. Not unreasonable, but you have to go through reflection and that's a red flag. 5. Mark the methods with attributes to discover them. 6. Still need to get "names" from them, and the methods will be "getName". So you have to unmangle those. My answer is a regular, everyday interface method. 5. Check that the class implements the proper interface. 6. Call the particular method in the interface that returns a set of keys (names) and values (RankedListInterfaces).