vweb only check if the mime type for a file exists in the global const vweb.mime_types, any mime type set in the request context gets ignored.
This PR fixes this by always first checking if the mime type exists in the context.static_mime_types, which also allows overriding the default mime type with a custom mime type.

🤖 Generated by Copilot at df03ce1

Improve MIME type handling for static files in vweb. Add custom MIME type support and use it in vlib/vweb/vweb.v.

🤖 Generated by Copilot at df03ce1

• Add checks for ctx.static_mime_types map when serving static files (link, link, link, link)

If you want to set a custom mime type you should do it with Context.set_content_type. The Context.file is missing a check to see if ctx.content_type is already set. I think that should be changed.

I don't think the static_mime_types map in the Context should be changed.

Wouldn't that solution prevent us from setting custom mime types for a custom static file type?

The use case I have is that I also serve .map files for javascript files, which are not set in the vweb.mime_type global.
We could add the correct mime type to the global(and we should), but I think it will be difficult to have a map with all known file types known to man, and without being able to change the static_mime_types it will be impossible to have static folders with custom file types.

I think the ability to overwrite the set mime type is also important, as it could be that a client needs a specific content type set, which means you would have to write a whole custom handler instead of simply setting the mime type in the static map.

I agree that custom static types/custom file mimetypes are important.

The problem is that .map files have no defined standard mimetype (https://www.iana.org/assignments/media-types/media-types.xhtml).

The current problem is that serve_static and file don't allow custom types.

A custom file type could be send like this:

ctx.set_content_type('my mime')
ctx.file(file)

or serve_static(file, path, mime_type).

I think the implementations of file, serve static and send_response_to_client should be changed.

This would not allow for mixed custom mime type files in a single static folder.
If you call serve_static it will only set the mimetype for the given url, not for each specific files.
If we don't need/want to handle that case modifying the functions is fine.

Ah I understand your use case. I still don't think the custom mime types should be placed in static_mime_types.

But how do you feel about a property custom_mime_types on the Context? scan_static_directory would check vweb.mime_types and ctx.custom_mime_types. Then in serve_static the custom mime type is added to static_mime_types.

I think that would be fine, but it has to be documented that the static_mime_types is basically a readonly property.
There could be a problem with having two different properties which are basically the same, but if we can hide the static_mime_type then it should be fine

I would implement the change in the following way:
We add a pub mut Context.custom_mime_type on the Context struct, where we can set and override the Context.static_mime_types.
If we do this, I think we should set the access to Context.static_mime_types to private and make a getter, so it is communicated clearly that it is a readonly property.

pub struct Context {
mut:
	content_type string = 'text/plain'
	status       string = '200 OK'
       //Make  it private
	static_mime_types map[string]string
pub:	
	// HTTP Request
	req http.Request
	// TODO Response
pub mut:
	done bool
	// time.ticks() from start of vweb connection handle.
	// You can use it to determine how much time is spent on your request.
	page_gen_start i64
	// TCP connection to client.
	// But beware, do not store it for further use, after request processing vweb will close connection.
	conn              &net.TcpConn = unsafe { nil }
	static_files      map[string]string
	// Map containing query params for the route.
	// http://localhost:3000/index?q=vpm&order_by=desc => { 'q': 'vpm', 'order_by': 'desc' }
	query map[string]string
	// Multipart-form fields.
	form map[string]string
	// Files from multipart-form.
	files map[string][]http.FileData

	header http.Header // response headers
	// ? It doesn't seem to be used anywhere
	form_error                  string
	livereload_poll_interval_ms int = 250
}
//new getter
pub fn (ctx Context) list_mime_types() map[string]string{
	return ctx.static_mime_types
}

I think your idea with the ability to(optionally) manually specify the mime type for the file is a good idea regardless of the other points and if it's ok I would send a pr for that.
But do we also check Context.static_mime_types in this methode?
Or only static?

Yes also check the static files map. The changes look good to me, sorry for the confusion .

Fixed in the new vweb module x.vweb