flipped-aurora/gin-vue-admin · error

function file.Open() Failed, err:

Error message

function file.Open() Failed, err:

What it means

This error is returned by Minio.UploadFile when file.Open() fails to open the multipart file from the HTTP request. This usually means the multipart form data was malformed, the request body was already consumed, or the upload exceeded the server's multipart memory/size limits in a way that corrupted the part.

Source

Thrown at server/utils/upload/minio_oss.go:53

	})
	if err != nil {
		return nil, err
	}
	return minioClient, nil
}

func (m *Minio) UploadFile(ctx context.Context, file *multipart.FileHeader) (filePathres, key string, uploadErr error) {
	client, err := newMinioClient()
	if err != nil {
		logger.WithCtx(ctx).Mod("upload").Err(err).Error("minio client 初始化失败")
		return "", "", errors.New("minio client 初始化失败, err:" + err.Error())
	}

	f, openError := file.Open()
	// mutipart.File to os.File
	if openError != nil {
		logger.WithCtx(ctx).Mod("upload").Err(openError).Error("function file.Open() Failed")
		return "", "", errors.New("function file.Open() Failed, err:" + openError.Error())
	}

	filecontent := bytes.Buffer{}
	_, err = io.Copy(&filecontent, f)
	if err != nil {
		logger.WithCtx(ctx).Mod("upload").Err(err).Error("读取文件失败")
		return "", "", errors.New("读取文件失败, err:" + err.Error())
	}
	f.Close() // 创建文件 defer 关闭

	// 对文件名进行加密存储
	ext := filepath.Ext(file.Filename)
	filename := utils.MD5V([]byte(strings.TrimSuffix(file.Filename, ext))) + ext
	if global.GVA_CONFIG.Minio.BasePath == "" {
		filePathres = "uploads" + "/" + time.Now().Format("2006-01-02") + "/" + filename
	} else {
		filePathres = global.GVA_CONFIG.Minio.BasePath + "/" + time.Now().Format("2006-01-02") + "/" + filename
	}

View on GitHub (pinned to 3136500ef3)

Solutions

  1. Check the appended openError: 'http: request body too large' or unexpected EOF means increase/align body size limits across client, proxy, and Gin.
  2. Raise nginx client_max_body_size (and proxy read timeout) and Gin MaxMultipartMemory if handling large files.
  3. Verify the client actually sends multipart/form-data with the correct field name and completes the request.
  4. Ensure the request context/body is not consumed or closed before UploadFile is invoked.

Example fix

// before (nginx)
client_max_body_size 1m;   # 100MB upload truncated
// after (nginx)
client_max_body_size 200m;
proxy_read_timeout 300s;
Defensive patterns

Strategy: validation

Validate before calling

// before calling UploadFile, verify the FileHeader is openable and within limits
if fileHeader == nil || fileHeader.Size <= 0 {
    return errors.New("empty or missing upload")
}
if fileHeader.Size > maxUploadSize {
    return fmt.Errorf("upload %d bytes exceeds limit %d", fileHeader.Size, maxUploadSize)
}
probe, err := fileHeader.Open()
if err != nil {
    return fmt.Errorf("upload part unreadable: %w", err)
}
probe.Close()

Try / catch

filePath, key, err := minioUploader.UploadFile(ctx, fileHeader)
if err != nil {
    if strings.HasPrefix(err.Error(), "function file.Open() Failed") {
        return nil // client-side problem: return 400 asking the client to re-send
    }
    return err
}

Prevention

When it happens

Trigger: UploadFile called with a *multipart.FileHeader whose underlying part cannot be read: request body truncated by the client or a proxy, Gin's multipart memory limit exceeded (http.MaxBytesReader / engine.MaxMultipartMemory), or the FileHeader was constructed outside a real request context.

Common situations: Reverse proxy (nginx) buffering limits cutting off large uploads; client closing the connection early; missing enctype="multipart/form-data" producing a FileHeader the server can't open; file size beyond server body limit middleware.

Related errors


AI-assisted analysis of flipped-aurora/gin-vue-admin@3136500ef3 (2026-08-31). Data as JSON: /api/errors/a2bf8ae3aa1471e5. Report an issue: GitHub.