Asked  7 Months ago    Answers:  5   Viewed   48 times

I have been trying to submit a form with enctype="multipart/form-data". I have this setting because the form will involve jpeg/png uploads once I have figured out the ajax submission for text inputs.

  1. the php works fine when referencing the script using action within the form html.

  2. the form data seems to be retrieved correctly by the below jquery because the alert line shows: productName=Test+Name&productDescription=Test+Description&OtherProductDetails=

  3. the returned data printed to my HTML by the jquery success function is a php error saying:Undefined index: productName

  4. removing contentType:false fixes the problem.

When i google jquery/ajax multipart/form-data submission, the top hits at least mainly include 'contentType:false'. Please could someone explain the reason to me? Sending multipart/formdata with jQuery.ajax

The jquery API documentation says: contentType (default: 'application/x-www-form-urlencoded; charset=UTF-8') Type: String When sending data to the server, use this content type.

Why would we need to set it to false for a multipart/form-data submission? When would the false setting be needed at all?


  $("#addProductForm").submit(function (event) {
      //grab all form data  
      var formData = $(this).serialize();

          url: 'addProduct.php',
          type: 'POST',
          data: formData,
          async: false,
          cache: false,
          contentType: false,
          processData: false,
          success: function (returndata) {
          error: function () {
              alert("error in ajax form submission");

      return false;



contentType option to false is used for multipart/form-data forms that pass files.

When one sets the contentType option to false, it forces jQuery not to add a Content-Type header, otherwise, the boundary string will be missing from it. Also, when submitting files via multipart/form-data, one must leave the processData flag set to false, otherwise, jQuery will try to convert your FormData into a string, which will fail.

To try and fix your issue:

Use jQuery's .serialize() method which creates a text string in standard URL-encoded notation.

You need to pass un-encoded data when using contentType: false.

Try using new FormData instead of .serialize():

  var formData = new FormData($(this)[0]);

See for yourself the difference of how your formData is passed to your php page by using console.log().

  var formData = new FormData($(this)[0]);

  var formDataSerialized = $(this).serialize();
Wednesday, March 31, 2021
answered 7 Months ago

Another option is to have your controller return something other than a response and use the kernel.view event to transform that into what you want. This would be better DRY because the logic is encapsulated in the listener. You just need to decide what you want your controllers to return.

if ($form->isValid()) {
    return new Something($redirectUrl, $ajaxData);

And in your listener:

public function onKernelView($event)
    $request = $event->getRequest();
    $result = $event->getControllerResult();

    if ($result instanceof Something) {
        if ($request->isXmlHttpRequest()) {
            $event->setResponse(new Response(json_encode($result->getAjaxData())));
        } else {
            $event->setResponse(new RedirectResponse($result->getRedirectUrl()));
Saturday, May 29, 2021
answered 5 Months ago

That happens because jQuery converts the data you pass in to a string in the format of a form, with a application/x-www-form-urlencoded header, which is something PHP recognizes and correctly creates the $_POST superglobal from.

Your native XMLHttpRequest sends the data as a string in JSON format with the application/json header, which PHP does not recognize as form data, and does not create a $_POST array from.

In modern browsers you can use formData to create valid form data that can be sent with ajax and recognized by PHP

Saturday, May 29, 2021
answered 5 Months ago

If you use XDebug, there is a maximum function nesting depth which is controlled by an ini setting:

$foo = function() use (&$foo) { 

Produces the following error:

Fatal error: Maximum function nesting level of '100' reached, aborting!

This IMHO is a far better alternative than a segfault, since it only kills the current script, not the whole process.

There is this thread that was on the internals list a few years ago (2006). His comments are:

So far nobody had proposed a solution for endless loop problem that would satisfy these conditions:

  1. No false positives (i.e. good code always works)
  2. No slowdown for execution
  3. Works with any stack size

Thus, this problem remains unsloved.

Now, #1 is quite literally impossible to solve due to the halting problem. #2 is trivial if you keep a counter of stack depth (since you're just checking the incremented stack level on stack push).

Finally, #3 Is a much harder problem to solve. Considering that some operating systems will allocate stack space in a non-contiguous manner, it's not going to be possible to implement with 100% accuracy, since it's impossible to portably get the stack size or usage (for a specific platform it may be possible or even easy, but not in general).

Instead, PHP should take the hint from XDebug and other languages (Python, etc) and make a configurable nesting level (Python's is set to 1000 by default)....

Either that, or trap memory allocation errors on the stack to check for the segfault before it happens and convert that into a RecursionLimitException so that you may be able to recover....

Saturday, July 3, 2021
answered 4 Months ago

can you try $.post instead of $.ajax

$.post(url, {argument_name: value, ...} , function(data){

// callback function..

}, 'json'}
Tuesday, August 31, 2021
Mateusz Pryczkowski
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :