Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #2158 (closed defect: fixed)

Opened 10 years ago

Last modified 10 years ago

Do not override the response content-type if it has already been modified.

Reported by: amcgregor Owned by: mramm
Priority: high Milestone: 2.1a1
Component: TurboGears Version: trunk
Severity: normal Keywords:
Cc:

Description

Currently there is a hack of a string constant used to prevent TG2 from altering the returned content-type.

# from tg.controllers

# If someone goes @expose(content_type=CUSTOM_CONTENT_TYPE) then we won't override pylons.request.content_type
CUSTOM_CONTENT_TYPE = 'CUSTOM/LEAVE'

This is a hideous hack. Instead, TG2 should detect changes to the content-type. By default it is configured as text/html. TG2 should not modify it if its value differs from this default, allowing controllers to override the content-type in the dynamic and Pylon-esque way:

@expose()
def download(self):
    response.content_type = self.mime
    response.content_disposition = 'attachment; filename="%s"' % self.name
    
    return self.data

Change History

comment:1 Changed 10 years ago by mramm

  • Priority changed from normal to high

comment:2 Changed 10 years ago by mramm

  • Status changed from new to assigned
  • Owner changed from percious to mramm

I checked in a change where this will work automatically IFF the response ( self.data above) is a string. If you're returning a dict, you still have to register cutstom types so that we can know what template engine to use.

Not sure if this is good enough, but I couldn't think of a use case where you'd not be returning a string when you want to manually set the content type in the controller.

comment:3 Changed 10 years ago by mramm

  • Status changed from assigned to closed
  • Resolution set to fixed

I'm going to close this for now, but feel free to reopen it if there's a use case I'm missing.

comment:4 Changed 10 years ago by jorge.vargas

what about getting rid of CUSTOM_CONTENT_TYPE , that's horrible code...

comment:5 Changed 10 years ago by jorge.vargas

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Milestone changed from 2.0b5 to 2.0rc1

comment:6 follow-up: ↓ 7 Changed 10 years ago by mramm

  • Milestone changed from 2.0rc1 to 2.1

We can deprecate them and remove post 2.0.

comment:7 in reply to: ↑ 6 Changed 10 years ago by jorge.vargas

Replying to mramm:

We can deprecate them and remove post 2.0.

I haven't tried this myself but I had reports from IRC that it (CUSTOM_CONTENT_TYPE) does not works right now. Can't we deprecate them in 2.0?

comment:8 Changed 10 years ago by mramm

Sure it can be deprecated now, and removed in 2.1

comment:9 Changed 10 years ago by percious

  • Milestone changed from 2.1 to 2.1a1

comment:10 Changed 10 years ago by jorge.vargas

  • Status changed from reopened to closed
  • Resolution set to fixed
  • Type changed from enhancement to defect

I'm closing this in favor of the more general #2378 mainly because, TG is not "disrespecting" the content_type rather it's having issues with the response object.

Note: See TracTickets for help on using tickets.