Skip to content
This repository was archived by the owner on Jun 27, 2023. It is now read-only.
This repository was archived by the owner on Jun 27, 2023. It is now read-only.

Better handling of content negociation #67

Open
@slorber

Description

@slorber

I reworked a little bit the stuff arround isStupidBrowser because I don't really like it and it is kind of meaningless.

I added a new helper class which provides:

  /**
   * The server knows which mime types it can produce, and the client sends with Accept http header its preferred mimeTypes.
   * Thus based on that, this method tries to find the best supported mime type that can be handled by the client.
   * It is the mime type that should be used in the client's response (and thus in the ContentType http header too)
   * @param supportedMimeTypes
   * @param acceptHeader
   * @return
   */
  def findAppropriateContentType(supportedMimeTypes: Set[String],acceptHeader: String): Try[String] = ???

This parses the header correctly with a library.

I have seen that there's also some banana RDF code that kind of do the same stuff.

See rww.play.PlayWriterBuilder#writerFor

I think this is not a very good idea to add coupling to banana for content negociation.

In some cases (like for redirection to html viewer or handling binary resources) we have to do it ourselves with non banana code, before banana even tries to find a writer.

The matter is that it may be possible that our content negociation code conflicts with the banana code and thus return a writer that was unexpected.

I think we should manually detect in which is the appropriate contentType for a reply, eventually handle redirect/html rendering, and then use this contentType to get the appropriate writer instead of letting banana decide (potentially differently)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions